.NET, интерфейс C# между бизнес-логикой и DAL
Я работаю над небольшим приложением с нуля и использую его, чтобы попытаться преподавать мне архитектуру и концепции проекта. Это-.NET 3.5, приложение WPF, и я использую Компактный Выпуск Sql в качестве своего хранилища данных.
Я работаю над слоем бизнес-логики и сейчас начал писать DAL. Я просто использую SqlCeComamnds для отправки по простым запросам и SqlCeResultSet для достигания результатов. Я начинаю разрабатывать свои методы Вставки и Обновления и здесь являюсь проблемой - я не знаю лучший способ получить необходимые данные из BLL в DAL. Я передаю в универсальном наборе? У меня есть крупный список параметров со всеми данными для базы данных? Я просто передаю в фактическом бизнес-объекте (таким образом связывающий мой DAL с материалом conrete в BLL?).
Я думал об использовании интерфейсов - просто передача IBusinessObjectA в DAL, который обеспечивает простоту, которую я ищу, не связывая меня СЛИШКОМ плотно с текущими реализациями. Что делает Вас, парни думают?
4 ответа
Если бы я был на вашем месте, я бы, вероятно, использовал LINQ to SQL для определения уровня доступа к данным - это сэкономит вам много работы по поддержке всего этого SqlCeFooBar и даст вам конструктор (своего рода) для поддержки вашей базы данных, которого вам не хватило бы в противном случае, используя SQL CE.
Так что в этом случае я бы, вероятно, довольно тесно связал уровень бизнес-логики с сущностями, открываемыми уровнем L2S. Обоснованием является то, что сущности являются бизнес-объектами, хотя и лишенными каких-либо сервисов.
Однако я бы, вероятно, не позволил сущностям забираться так далеко вверх по иерархии, как пользовательский интерфейс. На этом уровне гораздо разумнее использовать модель специально для представления - особенно учитывая, что вы используете WPF.
Конечно, все это зависит от размера и сложности вашего приложения. Я предполагаю, что это довольно небольшое приложение (для одного пользователя?), учитывая, что вы используете SQL CE.
Я не думаю, что есть простой ответ на ваши вопросы, потому что есть много вариантов в зависимости от обстоятельств. Я счел полезным прочитать две приведенные ниже книги, которые помогут мне лучше понять проблемы, которые вы описываете.
- MS .NET: Архитектура приложений для предприятия (Эспозито, Салтарелло)
- Руководство по архитектуре приложений MS, 2-е издание.
Вторая книга доступна в Интернете. Посмотрите здесь .
Я думаю, что можно передать бизнес-объект на уровень доступа к данным. Я думаю, что задача BLL - просто работать со своими объектами, проверять, соблюдаются ли все правила, что может быть сохранено, кем, на каких полях, времени и т. Д.
Как только он это сделал, он должен пройти это в DAL, и я думаю, что ЭТО задача - выяснить, как преобразовать то, что он получил, во что-то, что можно сохранить, но он не будет проверять, что сохраняется или читается или кем, он просто сделает это. Это может быть прямо вперед, а-ля linq, но если ваши логические mdoels не соответствуют вашей модели данных 1: 1, тогда DAL должен выполнить все преобразование.
Что касается привязки вашего DAL к вещам в BLL, я думаю, вам следует позаботиться об обратном, привязав ваш BLL к вашему DAL. Я бы использовал интерфейс для представления вашего DAL (как в IRepository), чтобы вы могли заставить свой BLL вызывать любой механизм устойчивости, просто изменив тип IRepository, который он использует (дополнительные баллы, если вы используете IoC: P). Конкретные классы, реализующие IRepository, будут привязаны к бизнес-объектам, но они должны знать, что они сохраняют, не так ли? в то время как BLL НЕ должен знать, что делает сохранение.
Передать бизнес-объект в DAL - это самый простой и быстрый способ. Он работает в небольших проектах, но имеет те же недостатки:
1) Бизнес-объекты являются частью уровня BLL, и если вы передаете объекты в BLL, то DAL становится зависимым от BLL. нижний слой знает о верхнем - это вообще противоречит идее слоев.
2) Бизнес-объекты обычно очень сложны, чтобы сохранить их непосредственно в BD. В этом случае лучше ввести новый промежуточный слой «Mappers».
Чтобы решить все эти проблемы, я обычно делаю интерфейс для DAL независимым от Business Objects. Вместо этого я использую классы «Строка» - представление одной записи в базе данных или XML. В .NET 3.5 для этой цели можно использовать автоматически сгенерированные классы linqtosql.