Theo tôi, bạn nên LUÔN sử dụng một BLL (Business Logic Layer) giữa tầng web của bạn và Dal của bạn (Data Access Layer).
tôi đánh giá cao cho một số chi tiết truy vấn "đơn giản", BLL sẽ bắt chước chặt chẽ việc Dal (ví dụ Fetch tất cả các nước, Fetch tất cả các loại sản phẩm vv), nhưng để trung thực, ngay cả trong ví dụ của bạn:
(Fetch tất cả khách hàng với họ là của 'Atwood')
có "logic kinh doanh" được bày tỏ ở đây - Một mong muốn cho các hồ sơ dữ liệu được lọc bởi họ, nếu không có gì khác! Bằng cách thực hiện BLL từ khi bắt đầu dự án, nó trở nên vô cùng dễ dàng để chèn hoặc xác nhận hoặc bổ sung "logic" và khi nhu cầu có thể phát sinh (và nếu dự án của bạn là một ứng dụng thương mại, nhu cầu đó sẽ gần như chắc chắn phát sinh sau cùng nếu nó không có ở đầu dự án). Thêm trong logic bổ sung như:
Fetch tất cả các khách hàng đã dành hơn $ 10000 năm nay
hoặc
Không cho phép khách hàng với cái tên là 'Atwood' để mua các sản phẩm trên $ 1000
trở nên dễ dàng hơn đáng kể khi có BLL thực sự tham gia, thay vì cố gắng thu hẹp logic này vào cấp web.
Lưu ý rằng với các loại truy vấn ở trên, chúng tôi gần như chắc chắn nói về nhiều thực thể và bảng cơ sở dữ liệu sẽ phải tham gia cùng với các mối quan hệ được xác định cụ thể để thực hiện chức năng này. Cố gắng để đạt được điều này bằng cách trực tiếp thao tác DAL trở nên lộn xộn vì bạn sẽ xử lý nhiều thực thể và các lớp. Một BLL ở đây sẽ đơn giản hóa rất nhiều mã tầng web của bạn, vì BLL sẽ encapsulate các mối quan hệ thực thể đó đằng sau một giao diện được đơn giản hóa rất nhiều.
Điều này "separation of concerns" trở nên ngày càng quan trọng khi nào và nếu nhu cầu thay đổi giao diện người dùng phát sinh. Trong ít nhất hai lần khác nhau, tôi đã làm việc trên các ứng dụng web thương mại với giao diện người dùng trang web và cuối cùng đã được yêu cầu (do nhu cầu kinh doanh phát sinh từ khách hàng tìm kiếm tích hợp lớn hơn trong các sản phẩm phần mềm của họ) để sản xuất giao diện web service cung cấp chức năng giống hệt như trang web.
Tôi đã nhúng bất kỳ logic nghiệp vụ nào trong cấp web của mình, tôi sẽ phải sao chép và viết lại logic đó khi triển khai dịch vụ web của mình. Vì vậy, tôi đảm bảo rằng tất cả logic nghiệp vụ được gói gọn trong các lớp BLL, điều này có nghĩa là tôi chỉ cần thiết kế một loạt các cuộc gọi phương thức giao diện dịch vụ web và cắm các cuộc gọi này lên các phương thức trên các lớp BLL (Facade Design Pattern ở những nơi để đơn giản hóa API dịch vụ web).
Trong tất cả, tôi có thể nghĩ không có lý do gì để NOT bao gồm lớp BLL giữa DAL và cấp web của tôi. Khi nó dễ dàng nhất, khi BLL gần giống "bắt chước" DAL, có, có vẻ như là một bản sao của mã và chức năng, tuy nhiên, trong khi gõ nhiều hơn một chút, điều này cũng làm cho nó tương đối dễ thực hiện.
Khi nó liên quan nhiều hơn (như khi logic kinh doanh quan trọng tồn tại ngay từ đầu), việc tách mối quan tâm giúp giảm sự lặp lại (nguyên tắc DRY) đồng thời đơn giản hóa việc bảo trì trong tương lai và liên tục.
Tất nhiên, điều này giả định bạn đang làm tất cả điều này "bằng tay". Nếu bạn mong muốn, bạn có thể đơn giản hóa đáng kể các lớp DAL/BLL/UI bằng cách sử dụng một số ORM trong đó có rất nhiều! (ví dụ: LINQ-to-SQL/Entities, SubSonic, NHibernate v.v.)
Chồi câu hỏi tuyệt vời! –