Связь между BLL и DAL

Question

Настройка решения:

• DAL (класс библиотеки)
• BLL (класс библиотеки)
• Общие (класс библиотеки (некоторые общие функциональные возможности - enums, регистрация, исключения, ...))
• Application1 (приложение Windows)
• Приложение2 (приложение Windows)
• WebApp (веб-приложение)
• ...

Скажем, у меня есть Клиент Сущность, которое является:

• Таблица в SQL Server
• У клиенты передаваемых в Дал
• Класс клиента в BLL
• класс BLL.Customer во всех приложениях

Какие предметы должны использовать BLL и DAL для связи - DataTable или List<Customer> (Например)? В первом случае логика BLL должна преобразовать объект клиента к DataTable и отправлять его в DAL. В случае SECOD слой DAL должен знать о классе клиента, который находится в уровне BLL. Но оригинал DLL ссылок на дал и не напротив ...

Должен ли я поставить все классы на отдельную сборку, которая ссылается все остальные (общие, бизнесобщие, ...)? В этом случае я мог бы использовать класс клиентов во всех моих проектах.

Должен ли я даже беспокоить опечатать Dal и Bll, когда я знаю, что только один BLL будет использовать мою далу. В этом случае я мог объединить их вместе в один проект.

PS - Я читаю о детаном и многие люди говорят, что мы не должны их использовать вообще. Что лучше вариантов? Может быть, мне пора изучать некоторые инструменты сопоставления ORM :)

Answer 1

На мой взгляд, у вас должен быть другой слой (отдельная DLL). Как и «домен», где бы вы держали все объекты, такие как клиент. Затем просто включите все более высокие уровни (DAL, BLL, UI и другие) в иерархии этой сборки.

Образец архитектуры может выглядеть так:

(База данных) <-> DAL <-> BL <-> UI

И на всех уровнях у вас будет доступ к слою «Домен». DAL должен вернуть списка не на канате. На некотором этапе ваш процесс разработки вы можете использовать в DAL, какой-то OMR, как NHIBERNATE, а также вернет список, возможно.

Answer 2

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

Мои следующие мысли - это просто предложение. Не стесняйтесь рассмотреть их и изменить / игнорировать то, что вы чувствуете, не относятся.

Разделение DAL из BLL почти всегда хорошая идея. Схема данных - это одна вещь, которая должна быть инкапсулирована и скрыта от остальной части приложения, поэтому оставьте ваши данные, наборы данных, ORMS или любое другое решение, скрытое в DAL. BLL (и слои над ним) должны использовать простые типы данных (что означает простые классы). Я думаю, что было бы хорошей идеей поставить эти классы в библиотеке классов модели, которая не имеет ссылок и может использоваться везде.

Похоже, у вас слишком много слоя ... Вам действительно нужен класс клиента в BLL и еще один в слое приложений? Может быть, но я бы убедился и думал об этом дважды.

Из моего опыта в одном из моих недавних проектов (погодный веб-сайт с уникальными посетителями 200 000 ежедневно мы использовали link2sql для доступа к данным (в основном данные только с чтением), а также простые классы данных по всему нашему нашему приложению ASP.NET MVC (, конечно, как Часть моделей / просмотра моделей). Он работал довольно плавно, и мы могли бы легко изменить схему данных, не нарушая другие слои.

Что касается вашего последнего вопроса о бабочных данных, эти объекты, если вы решите их использовать (я бы голосул против), принадлежат исключительно в вашем DAL. Они не должны подвергаться воздействию других слоев, как это создало бы муфту к тому конкретному классу. Что если завтра MS приглашает гораздо лучший класс? Будете ли вы переключиться сейчас, когда у вас есть ссылки на Gazillion во всех ваших проектах к детаным материалам, его методу и свойствам? Было бы лучшее, чтобы просто изменить свой DAL для работы с классом Newawsomedatable, а остальная часть вашего приложения блаженно невежественна.

Надеюсь, что помог :)

Answer 3

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

UI/Consumer  <--- (view models) --> BLL <--- Models ----> DAL/Persistence

Здесь модели зрения потребляются за пределами BLL, а модели передаются через слои BLL / DAL.

В вашем случае модель может быть чем-то, что использует DAL - DataTables, например или позже, возможно, ORM-объекты. BLL отвечает за сопоставление между моделью и смотровой моделью.

Что касается хранения типов в своих собственных собраниях - да для моделей просмотра и для поддержания согласованности да и для моделей.

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

Одним из преимуществ этого разделения является то, что различные модели моделей представления могут иметь разные модели зрения для той же модели / сущности настойчивости. Некоторые могут быть маленькими и имеют мало атрибутов и других больших и богатых функциональными возможностями. Это также позволяет внести возможность внедрения в автономном режиме / отключения, поскольку моделями просмотра могут быть возвращены в разные времена, что позволяет вам решать стратегии объединения данных. Это также позволяет вам настойчивые объекты (например, столы для расти и изменения формы). Так как это выглядит как .NET реализация вещей, как Автомат предоставит много функциональности из коробки

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

Answer 4

Нажатие объектов домен в DAL - это опция, которая удаляла бы завидующую зависимость, но может не соответствовать вашему намерению. Это не неслыдно, хотя; Например, Linq-to-sql Gnerated сущности будут жить в DAL.

Другие варианты:

• положить их в общее ниже сборка (но это может оставить ваш BL CORE COREEPLE)
• Используйте IOC для удаления / обратной ссылки между BL / DAL

Здесь нет ни одного правильных ответов.

RE DataTable; Лично я согласен - я не фанат;) Однако их можно успешно использовать успешно и разумно. Но если я имел Чтобы использовать их, я бы держал их в DAL в качестве деталей реализации - и не подвергая их выше этого.