На мой взгляд, вам следует ВСЕГДА использовать BLL (Business Logic Layer ) между вашим веб-уровнем и DAL (уровнем доступа к данным).
Я ценю, что для некоторых из более простых запросов BLL будет точно имитировать DAL (например, Получить все страны, Получить все типы продуктов и т. Д.), Но, честно говоря, даже в вашем примере:
(Получите всех клиентов с фамилией «Этвуд»)
здесь выражается бизнес-логика - желание, чтобы записи данных фильтровались по фамилии, если не иначе!
Реализуя BLL с самого начала проекта, становится невероятно легко вставлять либо проверку, либо дополнительную логику, когда и когда может возникнуть необходимость (и если ваш проект является коммерческим приложением, эта потребность почти обязательно возникают в конечном итоге, если его нет в начале проекта). Добавление дополнительной логики, такой как:
Получите всех клиентов, которые потратили более 10000 долларов в этом году
or
Не позволяйте клиентам с фамилией «Этвуд» покупать товары на сумму более 1000 долларов.
становится значительно проще, когда задействован настоящий BLL, вместо того, чтобы пытаться загнать эту логику в веб-уровень.
Имейте в виду, что с типами запросов выше мы почти наверняка говорим о нескольких сущностях и таблицах базы данных, которые должны будут соединиться вместе с помощью специально определенных отношений, чтобы реализовать эту функциональность. Попытка достичь этого путем прямого управления DAL становится беспорядочной, поскольку вы будете иметь дело с несколькими сущностями и классами. BLL здесь значительно упростит код вашего веб-уровня, поскольку BLL будет инкапсулировать эту сущность отношения за значительно упрощенным интерфейсом.
Это разделение проблем становится все более важным, когда и если возникает необходимость в изменении пользовательского интерфейса.
По крайней мере, в двух отдельных случаях я работал над коммерческими веб-приложениями с пользовательским интерфейсом веб-сайта, и в конечном итоге меня попросили (из-за бизнес-потребностей, возникающих из-за того, что клиенты хотели большей интеграции в свои программные продукты) создать интерфейс веб-службы, предлагающий те же функции, что и веб-сайт.
Если бы я встроил какую-либо бизнес-логику в свой веб-уровень, мне пришлось бы дублировать и переписывать эту логику при реализации моей веб-службы. Как бы то ни было, я убедился, что вся бизнес-логика была инкапсулирована в классы BLL, а это означало, что мне просто нужно было спроектировать серию вызовов методов интерфейса веб-службы и подключить их к вызовам методов в классах BLL (на самом деле я использовал Шаблон проектирования фасадов (местами для упрощения API веб-службы).
В общем, я не могу придумать никаких причин для того, чтобы НЕ включать слой BLL между моим DAL и моим веб-уровнем.
В самом простом случае, когда BLL близко имитирует DAL, да, кажется, что существует дублирование кода и функциональности, однако, несмотря на то, что это немного больше набора текста, это также делает его относительно простым в реализации.
Когда это более сложно (например, когда важная бизнес-логика существует с самого начала), разделение задач помогает уменьшить повторение (принцип DRY), в то же время значительно упрощая будущее и текущее обслуживание.
Конечно, это предполагает, что вы делаете все это вручную. При желании вы можете значительно упростить уровни DAL / BLL / UI, используя ORM коих много! (например, LINQ-to-SQL / Entities, SubSonic, NHibernate и т. д.)
person
CraigTP
schedule
28.04.2009
