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

Question

установки

Решения:

• ВВЛ (библиотека классов)
• BLL (библиотека классов)
• Common (библиотека классов (некоторые общие функциональные возможности - перечисления, каротаж, исключение, .. .))
• Application1 (Windows Application)
• Application2 (Windows Application)
• WebApp (веб-приложение)
• ...

Допустим, у меня есть клиентов лицо, которое:

• таблица в SQL сервере
• в CustomerDataTable в DAL класса
• Клиент в УСК
• a BLL.Customer class во всех приложениях

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

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

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

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

Answer 1

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

Пример архитектуры может выглядеть следующим образом:

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

и на всех уровнях, вы будете иметь доступ к слою "домен". DAL должен возвращать List, а не DataTable. На каком-то этапе процесс разработки, который вы, возможно, захотите использовать в DAL, может быть, например, с помощью OMR, например NHibernate.

Answer 2

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

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

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

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

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

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

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

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

Answer 3

Нажатие объектов домена в dal - это опция, которая удаляет crcular-зависимость, но может не соответствовать вашему намерению. Однако это не неслыханно; например, связанные с LINQ-to-SQL объекты будут жить в DAL.

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

• поместить их в общую ниже сборки (но это может оставить BL довольно пусто)
• использовать МОК для удаления/реверс ссылку между BL/DAL

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

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

Answer 4

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

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

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

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

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

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

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