Бизнес-объекты и уровень данных

То, как я это делаю, - это то, что БО ожидает DataReader или DataContext или что-то еще от DAL, а не фактически сформированный объект. Затем задача BO-слоя состоит в том, чтобы взять и заполнить себя от объекта, который вернулся. DAL не возвращает завершенный BO. Главное помнить, что изменение чего-либо на уровне BO не должно вызывать проблем для уровня DAL, но изменение чего-либо на уровне DAL может вызвать проблемы для уровня BO.

Краткий пример того, что я обычно делаю

В слое BO

FillData(){
   DataReader dr = DataLayer.GetData("SomePropertyForAStoreProcedure");
   If dr.Read(){
    Property1 = dr.GetValue("Property1");
    //So on and so forth
   }
}

В ДАЛ

DataReader GetData(String SPProperty){

}

взгляните на SubSonic http://subsonicproject.com/, он выполняет большую часть утомительной работы по доступу к данным за вас и это проще, чем большинство ORM

DAL нужна ссылка на BOL, чтобы он мог заполнять объекты. Чего вы не хотите, так это какой-либо ссылки или связывания из BOL обратно с DAL - это приводит к тому, что ваш BOL будет связан с конкретной реализацией базы данных. Если подумать, это имеет смысл. Ваш DAL знает подробности о бизнес-объектах вплоть до уровня свойств и того, как извлекать их данные из базы данных - конечно, DAL по своей сути тесно связан с BOL. Так что ссылка в таком виде прекрасна. А если задуматься, что на другой стороне? База данных. "Тесная связь" идет от данных вашего объекта к базе данных? Да, это чертовски сложно. Сама концепция даже не очень содержательна.

Это все другое направление, где вам нужно разъединиться. Итак, да, пока нет прямой связи между DAL и BOL, вы можете изменить свою платформу данных как хотите.

Нет особого смысла создавать интерфейсы для BO и передавать их в DAL в этом сценарии. Однако иногда вам может понадобиться пойти другим путем. Как правило, бизнес-объекты не должны знать ничего о том, как они создаются или сохраняются.

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

Если вы чувствуете, что нет лучшего способа, и вам нужно, чтобы что-то сохранялось внутри BOL, создайте простой интерфейс, чтобы функциональность DAL могла быть передана в BOL. Таким образом, вы по-прежнему можете отделить BOL от конкретной реализации базы данных, по крайней мере.

Кроме того, хотя это большая дополнительная работа, я настоятельно рекомендую вам также добавить еще один слой между пользовательским интерфейсом и BOL, если это не очень простое одноразовое приложение. Шаблон MVP (Model-View-Presenter) - это шаблон проектирования общего назначения для уменьшения связи между основным приложением и пользовательским интерфейсом. Существует множество вариантов докладчиков, не вдавайтесь в подробности, просто начните с простого MVP, если вы никогда его не использовали.

Шаблоны не так уж сложны, просто сам пользовательский интерфейс настолько запутан, что вам может потребоваться как минимум пара основных итераций / приложений, прежде чем вы почувствуете, что код, который вы пишете в любое время, систематически и методично работает над разделением UI. Просто продолжайте работать над этим, начните осваивать целый арсенал техник и не зацикливайтесь на том факте, что вы действительно еще не достигли четкого разделения. Все, что вы изучаете и можете сделать, что даже немного способствует созданию четко определенной границы в пользовательском интерфейсе, является большим шагом в правильном направлении.

«Правильный» подход будет варьироваться в зависимости от потребностей бизнеса. Честно говоря, есть много проектов, в которых, как мне кажется, старые наборы записей Adobe требовали меньше времени на разработку и их было легче поддерживать, чем многие из существующих сейчас ORM. Найдите время, чтобы определить свои потребности, и помните, что время разработки и ремонтопригодность - это цели дизайна, которые также следует должным образом взвесить.

Это также зависит от того, какую библиотеку / ORM (Object-Relational Mapper) вы используете. При использовании (хорошего) ORM, DAL должен быть очень удаленной проблемой, потому что он почти полностью скрыт ORM; однако передовой опыт диктует, что даже в этом случае для приложений среднего и большого размера следует ввести еще один уровень между BOL и ORM, обычно DTO (объекты передачи данных). DTO также могут использоваться без ORM, поскольку это просто немые объекты, определенные в отдельной библиотеке, и DAL может нести ответственность за их сохранение (преобразование их из / в структуры базы данных), в то время как BOL может запрашивать DAL и получать их. объекты.

Разделение уровней может быть достигнуто различными способами, чаще всего через интерфейсы и / или MEF или другую структуру DI / IOC. Любой такой метод обеспечивает более чем достаточную развязку при эффективном использовании.

Кроме того, в зависимости от используемой технологии, как сказал Сизиф, один из многоуровневых архитектурных шаблонов поможет хорошо разделить проблемы: MVC, MVP, MVVM и т. Д. Я лично рекомендую MVVM с WPF (настольный компьютер) или Silverlight (веб), но я очень предвзято - т.е. люблю их обоих до смерти :)

Это мои выводы,
1. Используйте интерфейсы
2. Используйте DTO [объекты передачи данных] между DAL и BLL
3. Разделите BLL на два,
a. BLL
b. Service Layer
4. Используйте контейнер Inversion of Control (IoC), чтобы поддерживать связь как можно ниже.