Вы разрешаете веб-уровню напрямую обращаться к DAL?

Ответ 1

По-моему, вы должны ВСЕГДА использовать BLL (Уровень бизнес-логики) между вашим веб-уровнем и ваш DAL (Уровень доступа к данным).

Я ценю, что для некоторых более простых запросов BLL будет точно имитировать DAL (например, Fetch all countries, Fetch all Product Types и т.д.), но честно, даже в вашем примере:

(Получить всех клиентов с фамилией 'Этвуд')

здесь выражается "бизнес-логика" - желание фильтровать записи данных по фамилии, если ничего другого!

Внедряя BLL с самого начала проекта, становится невероятно легко вставлять либо валидацию, либо дополнительную "логику", когда и когда может возникнуть необходимость (и если ваш проект является коммерческим приложением, эта потребность почти наверняка возникнет в конечном итоге если его нет в начале проекта). Добавление дополнительной логики, например:

Получить всех клиентов, которые потратили более $10000 в этом году

или

Не разрешайте клиентам с фамилией "Атвуд" для покупки предметов более 1000 долларов США

становится значительно легче, когда задействован настоящий BLL, вместо того, чтобы пытаться ломать эту логику в веб-уровень.

Имейте в виду, что с помощью описанных выше типов мы почти наверняка говорим о нескольких сущностях и таблицах базы данных, которые должны будут объединяться с определенными отношениями для реализации этой функции. Попытка добиться этого, непосредственно манипулируя DAL, становится беспорядочной, поскольку вы будете иметь дело с несколькими объектами и классами. BLL здесь значительно упростит ваш код веб-уровня, поскольку BLL будет инкапсулировать эти отношения сущностей за значительно упрощенным интерфейсом.

Этот " разделение проблем становится все более важным, когда возникает необходимость изменения пользовательского интерфейса.

В настоящее время, по крайней мере, в двух отдельных случаях, я работал над коммерческими веб-приложениями с пользовательским интерфейсом веб-сайта и в конечном итоге был спрошен (из-за необходимости бизнеса, возникающего от клиентов, стремящихся к большей интеграции в своих программных продуктах) для создания веб-сервис, предлагающий ту же функциональность, что и веб-сайт.

Если бы я встроил любую бизнес-логику в свой веб-уровень, мне пришлось бы дублировать и переписывать эту логику при реализации моего веб-сервиса. Как бы то ни было, я обеспечил, чтобы вся бизнес-логика была инкапсулирована в классы BLL, а это означало, что мне просто нужно было разработать серию вызовов метода интерфейса веб-сервиса и подключить их к вызовам методов на классах BLL (я фактически использовал шаблон оформления фасада в целях упрощения API веб-сервисов).

В целом, я не могу думать о том, что НЕ включает слой BLL между моим DAL и моим веб-уровнем.

В нем проще всего, когда BLL тесно "имитирует" DAL, да, похоже, что существует дублирование кода и функциональности, однако, будучи немного более типизированным, это также делает его относительно простым в реализации.

Когда он больше задействован (например, когда значительная бизнес-логика существует с самого начала), разделение проблем помогает уменьшить повторение (DRY), в то же время значительно упрощая будущее и текущее обслуживание.

Конечно, это предполагает, что вы делаете все это "вручную". Если вы этого желаете, вы можете значительно упростить слои DAL/BLL/UI, используя ORM, из которых их много! (т.е. LINQ-to-SQL/Entities, SubSonic, NHibernate и т.д.)

Ответ 2

Я не согласен с большинством сообщений здесь.

Я вызываю свой уровень данных в веб-уровне. Если между уровнем WEB/UI нет ничего, нет смысла создавать слой "на всякий случай". Это предварительная оптимизация. Это пустая трата. Я не могу вспомнить время, когда бизнес-уровень "спас меня". Все, что было сделано, было создано больше работы, дублирования и более высокого уровня обслуживания. Я потратил годы на подписку на уровень Business Layer → Data Layer между слоями. Я всегда чувствовал себя грязным, создавая прохождение методов, которые ничего не делали.

После введения Проект, управляемый доменом Эриком Эвансом, я делаю то, что имеет смысл. Если между пользовательским интерфейсом и слоем данных нет ничего, я вызываю слой данных в пользовательском интерфейсе.

Чтобы разрешить будущие изменения, я обертываю все классы Data Layer в интерфейсах. В пользовательском интерфейсе я ссылаюсь на интерфейсы, и я использую инъекцию зависимостей для управления реализацией. После внесения этих изменений это было похоже на глоток свежего воздуха. Если мне нужно что-то вводить между слоем данных и пользовательским интерфейсом, я создаю службу.

Еще одна вещь, которую я сделал, заключалась в сокращении числа проектов. Прежде чем у меня появится проект для уровня данных, бизнес-логики, бизнес-объектов и некоторого типа проекта пользовательского интерфейса - какая боль.

У меня есть два проекта: Основной проект (объекты, бизнес-логика и уровень данных) и проекты пользовательского интерфейса (веб-сайты, веб-службы и т.д.)

Для получения дополнительной информации я рекомендую посмотреть на этих ребят:

• Разработать с Passion
• Джеффри Палермо
• Дэвид Лариби

Ответ 3

Вам нужно отличить BLL-объекты (что, черт возьми, это в любом случае? Объекты домена кому-нибудь?) и Сервисы. Объекты вашего домена не должны иметь никакого отношения к вашему уровню доступа к данным. Что касается веб-уровня, он может обрабатывать ваши репозитории (думаю, IRepository), как и любые другие службы, которые он может свободно использовать.

Итак, нижняя строка: да, веб-уровень может напрямую использовать DAL при условии, что это свойство инкапсулировано и представлено как стандартная служба уровня обслуживания.

Ответ 4

Даже когда он включен, одна строка в BLL делает аналогичный вызов DLL, абстракция позволяет добавлять бизнес-логику в этот слой без необходимости влиять на другие слои. Возможно, это не похоже, вероятно, сейчас, но тот, кто должен поддерживать приложение после того, как вы поблагодарите вас за использование таких шаблонов, когда происходят изменения.

Что касается именования, у меня есть мой основной объект, скажем, NameChange, тогда у меня будет объект BLL, который является человеком, который принимает объект изменения имени, тогда у меня будет объект DAL/Entity, называемый Person. Объект Business Person находится в пространстве имен BLL, а объект DAL/Entity Person находится в пространстве имен DB (я бы выбрал DAL, если бы я его построил изначально).

Ответ 5

Мы рассматриваем этот слой как класс контроллера [layer], который инкапсулирует DAL из веб-уровня. Уровень контроллера может иметь или не иметь какой-либо бизнес-логики, он помогает отделить DAL от уровня представления и сохранить их независимыми [в некоторой степени].

Ответ 6

Мы использовали шаблон для доступа, хотя наш проект, в котором мы его используем, является значительным, я думаю, что он может докажите, что избыток излишков в меньшем проекте.

По существу:

UI → BusFacade → BusinessLogic → DalFacade → DataAccessLayer

фасад делает хороший/чистый подход от пользовательского интерфейса и заставляет вас стандартизовать ваши соглашения об именах, поскольку эта единственная точка ввода имеет ряд методов.

BusFacade.GetCmsSiteMap()
BusFacade.GetProductGroup()

etc.etc.

Ответ 7

В то время как можно было бы перейти непосредственно из уровня презентации в DAL, вы пропускаете BLL, который часто требует аутентификации...