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

Question

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

• DAL (библиотека классов)
• BLL (библиотека классов)
• Common (библиотека классов (некоторые общие функции - перечисления, ведение журнала,исключения, ...))
• Приложение1 (Приложение Windows)
• Приложение2 (Приложение Windows)
• WebApp (Веб-приложение)
• ...

Допустим, у меня есть сущность Customer , которая:

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

Какие объекты BLL и DAL должны использовать для связи - DataTable илиList<Customer> (например)?В первом случае логика BLL должна преобразовать объект Customer в DataTable и отправить его в DAL.Во втором случае уровень 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

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

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

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

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

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

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

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

Answer 3

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

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

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

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

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

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

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

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

Answer 4

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

Другие опции:

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

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

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