.net, C # Интерфейс между Business Logic и DAL

Question

Я работаю над небольшим приложением с нуля и использую его, чтобы попробовать себя в архитектуре и концепциях дизайна. Это приложение .NET 3.5, WPF, и я использую Sql Compact Edition в качестве хранилища данных.

Я работаю над уровнем бизнес-логики и только сейчас начал писать DAL. Я просто использую SqlCeComamnds для отправки простых запросов и SqlCeResultSet для получения результатов. Я начинаю разрабатывать свои методы вставки и обновления, и вот в чем проблема - я не знаю лучшего способа получить необходимые данные из BLL в DAL. Я передаю в общей коллекции? У меня есть огромный список параметров со всеми данными для базы данных? Я просто передаю фактический бизнес-объект (таким образом, привязывая мой DAL к конкретному материалу в BLL?).

Я думал об использовании интерфейсов - просто передавал IBusinessObjectA в DAL, что обеспечивает простоту, которую я ищу, без тесной привязки к текущей реализации. Что вы, ребята, думаете?

Answer 1

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

• MS .NET: Архитектура приложений для предприятия (Esposito, Saltarello)
• Руководство по архитектуре приложений MS, 2-е издание.

Вторая книга доступна онлайн. Смотрите здесь .

Answer 2

Передать бизнес-объект в DAL - самый простой и быстрый способ. Работает в небольших проектах, но имеет те же недостатки:

1) Бизнес-объекты являются частью слоя BLL, и если вы передаете объекты в BLL, DAL становится зависимым от BLL. нижний слой знает о верхнем - это вообще противоречит идее о слоях.

2) Business Object обычно очень сложен для сохранения его непосредственно в BD. В этом случае лучше ввести новый промежуточный слой «Mappers».

Чтобы преодолеть все эти проблемы, я обычно делаю интерфейс с DAL независимым от Business Objects. Вместо этого я использую классы «Row» - представление одной записи в базе данных или XML. В .NET 3.5 для этой цели могут использоваться автоматически сгенерированные классы linqtosql.

Answer 3

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

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

Что касается привязки вашего DAL к содержимому в BLL, я думаю, вам следует беспокоиться об обратном, связывая свой BLL с вашим DAL. Я бы использовал интерфейс для представления вашего DAL (как в IRepository) таким образом, чтобы вы могли заставить свой BLL вызывать любой механизм сохранения, просто изменив тип используемого IRepository (дополнительные очки, если вы используете IoC: P). Конкретные классы, которые реализуют IRepository, будут привязаны к бизнес-объектам, но они должны знать, что они сохраняют, не так ли? в то время как BLL НЕ должен знать, что делает экономию.

Answer 4

Если бы я был на вашем месте, я бы, вероятно, использовал LINQ to SQL для определения своего уровня доступа к данным - это сэкономит вам много работы, поддерживая весь этот материал SqlCeFooBar, и даст вам конструктор (своего рода) для поддержки база данных, которой в противном случае вам не хватало бы, используя SQL CE.

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

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

Конечно, все это зависит от размера и сложности вашего приложения. Я предполагаю, что это довольно мелкомасштабное приложение (однопользовательское?), Учитывая, что вы используете SQL CE.