По моему мнению, вы должны ВСЕГДА использовать BLL ( Уровень бизнес-логики ) между вашим веб-уровнем и вашим DAL ( Уровень доступа к данным ).
Я ценю, что для некоторых более «простых» запросов BLL будет близко имитировать DAL (например, «Выбрать все страны», «Выбрать все типы продуктов» и т. Д.), Но, честно говоря, даже в вашем примере:
(Получить всех клиентов с фамилией
'Atwood')
здесь выражается «бизнес-логика» - желание фильтровать записи данных по фамилии, если ничего больше!
Благодаря внедрению BLL с самого начала проекта становится невероятно легко вставить либо валидацию, либо дополнительную «логику», когда и когда это может понадобиться (а если ваш проект является коммерческим приложением, эта потребность будет почти конечно возникнет в конце концов, если его нет в начале проекта). Добавление в дополнительную логику, такую как:
Получить всех клиентов, которые потратили
более $ 10000 в этом году
или
Не разрешать клиентам с фамилией 'Atwood'
для покупки товаров на сумму более 1000 * 1026 долларов
становится значительно проще, когда задействован истинный BLL, чем пытаться взломать эту логику на веб-уровне.
Имейте в виду, что с указанными выше типами запросов мы почти наверняка говорим о нескольких сущностях и таблицах базы данных, которые должны будут объединяться вместе со специально определенными отношениями для реализации этой функциональности. Попытка достичь этого путем прямого манипулирования DAL становится грязной, поскольку вы будете иметь дело с несколькими сущностями и классами. BLL в данном случае значительно упростит код веб-уровня, поскольку BLL инкапсулирует те отношения сущностей, которые находятся за значительно упрощенным интерфейсом.
Это " разделение интересов " становится все более важным, когда и когда возникает необходимость изменить пользовательский интерфейс.
Теперь, по крайней мере, в двух отдельных случаях я работал над коммерческими веб-приложениями с пользовательским интерфейсом веб-сайта, и меня в конечном итоге попросили (из-за необходимости бизнеса, возникающей у клиентов, стремящихся к большей интеграции в своих программных продуктах), создать веб-сервис интерфейс, предлагающий те же функции, что и веб-сайт.
Если бы я внедрил любую бизнес-логику в свой веб-уровень, мне пришлось бы дублировать и переписывать эту логику при реализации моего веб-сервиса. Таким образом, я гарантировал, что вся бизнес-логика была инкапсулирована в классы BLL, а это означало, что мне просто нужно было разработать серию вызовов методов интерфейса веб-службы и подключить их к вызовам методов в классах BLL (на самом деле я использовал Шаблон проектирования фасадов в местах, упрощающих API веб-службы).
В целом, я не могу думать о том, чтобы НЕ включать слой BLL между моим DAL и моим веб-уровнем.
Проще всего, когда BLL близко «имитирует» DAL, да, похоже, что есть дублирование кода и функциональности, однако, хотя он немного больше печатает, это также делает его относительно простым для реализации.
Когда это более активно (например, когда существенная бизнес-логика существует с самого начала), разделение интересов помогает уменьшить количество повторений (принцип DRY ), в то же время значительно упрощая будущее и текущие процессы. техническое обслуживание.
Конечно, это предполагает, что вы делаете все это "вручную". При желании вы можете значительно упростить слои DAL / BLL / UI, используя ORM , которых много!
(т. е. LINQ-to-SQL / Entities , SubSonic , NHibernate и т. д.)