Lớp logic nghiệp vụ (BLL) sử dụng là gì?

Khi đọc về thực tiễn tốt cho các ứng dụng cơ sở dữ liệu, tôi thường xuyên bắt gặp những người ủng hộ cái gọi là "lớp logic kinh doanh" và tôi đang cố gắng quyết định xem dự án của mình có nên sử dụng một dự án hay không (đó là một dự án cá nhân nhỏ). Vấn đề của tôi nằm ở chỗ tôi không thể nghĩ ra bất cứ điều gì để BLL làm mà DAL không thể xử lý (thực hiện truy vấn và ánh xạ kết quả tới các đối tượng), vì vậy BLL của tôi chỉ gọi DAL mà không tự làm gì.

Có lẽ tôi sai về chính xác những gì DAL nên làm. Nhưng bất kể, loại BLL nào sẽ được mong đợi trong một ứng dụng quản lý cơ sở dữ liệu?

Đối với các ứng dụng nhỏ hơn, BLL của tôi thường bắt đầu dưới dạng truyền qua DAL. Tôi ổn với điều đó. Khi tôi "khám phá" các quy tắc kinh doanh, BLL là nơi tôi đặt chúng. Cuối cùng tôi cũng tìm thấy rất nhiều thứ cần thiết trong BLL khi tôi viết bài kiểm tra của mình. Đối với các ứng dụng cá nhân của riêng tôi, tôi tạo ra các quy tắc kinh doanh và BLL vẫn là nơi tôi đặt chúng. Đối với tôi, BLL là thứ phát triển theo thời gian. Tôi đã làm việc trong một dự án càng lâu, BLL của nó càng lớn.

Tôi có thể xem xét kết hợp BLL và DAL cho một dự án nhỏ không? Tôi có thể, ngoại trừ việc tôi thay đổi công nghệ DAL thường xuyên khi tôi thay đổi kiểu tóc và tôi muốn có một cái gì đó để tách mã khách hàng của mình khỏi đó.

BLL sẽ xử lý những thứ là một phần của miền doanh nghiệp, không phải là một phần của cơ sở dữ liệu và không phải là một phần của giao diện người dùng (thông thường). Ví dụ: sử dụng tuổi của khách hàng để xác định xem họ có đủ điều kiện để được giảm giá đặc biệt không. DAL không nên làm điều này, đơn giản là nên lấy dữ liệu khách hàng và sau đó lưu trữ nó với dữ liệu giảm giá sau khi BLL đã hoàn thành công việc của mình. DAL nên tập trung nhiều hơn vào CRUD. Trong các ứng dụng nhỏ, hai mối quan tâm có thể chồng chéo.

Andrew,

Các lớp logic nghiệp vụ là những gì bạn kết thúc khi bạn thực hiện phát triển theo hướng tên miền và tập trung vào các hoạt động cốt lõi của tên miền. Nếu bạn loại bỏ lớp trình bày (gui, web) và lớp cơ cấu hạ tầng (db, kết nối mạng, v.v.), bạn đã có các hoạt động cốt lõi là một phần của tên miền của mình, chẳng hạn như gửi tiền vào tài khoản ngân hàng. Bây giờ nếu bạn đã mô hình hóa lớp doanh nghiệp của mình và tách biệt nó khỏi trình bày và cơ sở hạ tầng, bạn có thể chuyển nó dễ dàng sang các mục đích sử dụng khác, chẳng hạn như web hoặc thiết bị di động. Đó là một cách rõ ràng để suy nghĩ về sự phát triển và từ những gì tôi đã thấy, thật không may là điều đó thật đáng tiếc.

Tôi khuyên bạn nên tiếp cận với Eric Evans - Domain Driven Design, đây là một cuốn sách hay chứng minh các nỗ lực phát triển tập trung vào tên miền. Phải thừa nhận rằng, đó là một chút khó khăn khi đọc nửa chừng, nhưng nó tạo ra động lực và có một số niềm tin chắc chắn về những gì các nhà phát triển đang làm sai với các hệ thống ngày nay.

Không có gì nói rằng bạn PHẢI có một số tầng hoặc lớp nhất định. Tất cả phụ thuộc vào sự phức tạp của dự án của bạn. Hãy xem nhiều ứng dụng mẫu MVC, như nerd Dinner hoặc record store .. tất cả chúng đều sử dụng 2 lớp vì đối với các ứng dụng có rất ít logic xử lý, điều đó không có nghĩa gì cả.

Tuy nhiên, ngay cả khi ứng dụng của bạn nhỏ, nó có thể được lợi từ việc trừu tượng hóa lớp dữ liệu khỏi lớp trình bày thông qua lớp thứ ba thường là lớp doanh nghiệp. Điều này cho phép bạn thực hiện các thay đổi ở một nơi duy nhất, thay vì trên tất cả các lớp trình bày của bạn.

Giả sử bạn quyết định thay đổi ORM của mình từ Linq sang SQL thành Entity Framework (hoặc nhibernate). Có thể dễ dàng thay đổi nó trong lớp nghiệp vụ hơn trong lớp trình bày của bạn, vì bản trình bày có xu hướng kết hợp chặt chẽ với mô hình trình bày của nó.

Nếu bạn hiểu MVC, nghĩa là .. Model View Controller, bạn có thể nghĩ về kiến ​​trúc ứng dụng của mình theo các thuật ngữ tương tự. Mô hình không phù hợp với lớp dữ liệu của bạn, lớp Trình bày là Chế độ xem và Lớp nghiệp vụ là Trình điều khiển.

Bổ sung câu trả lời của hành tinh hoang vắng về thiết kế hướng tên miền:

Ngoài ra, hãy xem Kiến trúc Onion , rất phù hợp với các khái niệm Thiết kế hướng miền.

Lưu ý cách "Lớp" logic nghiệp vụ là cốt lõi của củ hành và mọi lớp cơ sở hạ tầng (như lớp truy cập dữ liệu) là các phụ thuộc bên ngoài của nó. Điều này giúp kiểm tra rất nhiều, bởi vì bạn sẽ có thể giả định mọi phụ thuộc cơ sở hạ tầng bên ngoài và kiểm tra đầy đủ logic tên miền của bạn.

Theo tôi: Lớp Logic nghiệp vụ là nơi "giải pháp khái niệm thuần túy" sống. Phần còn lại chỉ là chi tiết thực hiện cơ sở hạ tầng.

Tuy nhiên, một số ứng dụng có thể không cần loại kiến ​​trúc này. Nếu tất cả các ứng dụng của bạn là tập dữ liệu CRUD hoạt động, 'giải pháp khái niệm thuần túy' của bạn trên thực tế có thể trống và tất cả những gì bạn cần là một mặt trước chỉnh sửa cơ sở dữ liệu. Trong trường hợp đó, có lẽ bạn chỉ nên tập trung vào các lớp DAL và UI.

Câu trả lời cho câu hỏi này là (IMHO): "tôi có thể thay thế hoàn toàn DAL của mình và không phải viết lại bất kỳ mã logic kinh doanh nào không"?

Hãy nghĩ về nó giống như lớp trình bày của bạn - khá phổ biến khi nghĩ đến việc thay đổi GUI cho một cái khác, GUI máy tính để bàn dày được hoán đổi cho một máy khách web, được đổi chỗ cho ứng dụng iPhone. Nó không quá phổ biến để nghĩ như thế này đối với BLL / DAL vì chúng không bao giờ thực sự bị tráo đổi ngoại trừ có thể là thứ gì đó rất giống nhau (ví dụ: SQLServer DB được thay thế bằng MySQL), nhưng nếu bạn tưởng tượng bạn phải thay đổi DB của mình thành bộ lưu trữ phân tán dịch vụ được truy cập bằng API, bạn có thể hiểu rõ hơn về nơi các lớp gặp nhau.