Слой Бизнес-логики и Уровень доступа к данным: круговая зависимость
Хорошей идеей является использование «объектно-реляционного картографа», подобного Idiorm :
$user = ORM::for_table('user')
->where_equal('username', 'j4mie')
->find_one();
$user->first_name = 'Jamie';
$user->save();
$tweets = ORM::for_table('tweet')
->select('tweet.*')
->join('user', array(
'user.id', '=', 'tweet.user_id'
))
->where_equal('user.username', 'j4mie')
->find_many();
foreach ($tweets as $tweet) {
echo $tweet->text;
}
Он не только избавляет вас от SQL-инъекций, но и от синтаксических ошибок! Также поддерживает коллекции моделей с цепочкой методов для фильтрации или применения действий к нескольким результатам сразу и нескольких подключений.
7 ответов
Я думаю, что Ваш шаблон доступа к данным прекрасен. То, что Вы не делаете, связывает Ваш BLL с OracleDAL. Вы связываетесь с интерфейсами DAL. Определенный бит связи абсолютно требуется, или Вы ничего никогда не могли делать.
я предполагаю, что Ваш DataFactory и классы INewsItemRepository существуют вне Вашего Слоя DAL. Следующее является примером того, как организованы мои решения. Я не использую ActiveRecord, таким образом, это не может подойти Вам отлично.
Core (Project)
Domain
Business Entities
Data
Repository Interfaces
**Your DataFactory**
OracleData (Project)
Data
Oracle Repository Implementations
SqlData (Project)
Data
Sql Repository Implementations
UI (Project)
Hope это помогает.
Можно использовать интерфейсы/внедрение зависимости для решения проблемы.
Ваш бизнес-слой (BL) содержит интерфейсы доступа к данным (DA), которые (возможно больше чем один) должен реализовать DAL. Проекты DAL имеют ссылки проекта к BL так, чтобы они могли выложить бизнес-объекты (BOS) и реализовать интерфейсы DA.
Ваш BOS может назвать DataFactory, который может инстанцировать объекта DA через внедрение зависимости или отражение.
я использовал этот шаблон во многих наших приложениях здесь на работе (и веб-и умный клиент), и это работает красиво.
Просто чтобы прояснить, мне нравится думать о бизнес-модели и бизнес-логике как о двух отдельных слоях. Ваша бизнес-модель - это ваши POCO (простые старые объекты CLR). Ваш уровень бизнес-логики будет отвечать за выполнение проверок, транзакций и т. Д. С использованием как вашей бизнес-модели, так и интерфейса с вашим DAL, который может быть подключен несколькими способами (Spring, Castle или ваш собственный собственный контейнер IoC).
Хороший способ достичь нулевых зависимостей в вашем DAL с помощью вашей бизнес-модели - это использовать уже созданную среду отображения отношений объектов (ORM), такую как NHibernate (бесстыдный плагин для моей любимой платформы ORM).
IceHeat, @Craig пример Wilson's имеет большую часть смысла и , вероятно полученный на основании этой статьи: http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx .
Это Определенно стоит чтения и занимается доменом управляемая разработка, которая решает проблемы, с которыми Вы сталкиваетесь здесь. Идентификатор рекомендует его любому, даже если Вы не даете обезьян о NHibernate, это - большая статья.
Я бы удалил любой метод Get () и Save () из BLL (модель предметной области) .. вот что я хотел бы сделать
GUI попросит репозиторий получить объект домена по идентификатору ... и один раз В GUI есть объект домена, по которому можно перемещаться, чтобы добраться до других объектов. Таким образом, слою домена не нужно ничего знать о репозиториях.
Внутри хранилища вы можете вернуть объект домена, который лениво загружает или полностью загружает граф объекта-объекта ... это будет зависеть от ваших потребностей.
Вот хорошая статья на ту же тему ... Восстановление объектов
Прочтите комментарий Деяна Петрова о том, как использовать динамический прокси
DAL должен быть абстрактным, таким образом, он должен содержать только плоскость объекты ADO.NET, которые взаимодействуют с базой данных бэкенда, например, соединением DataAdapter, DataReader и так далее. С этим под рукой можно сослаться на DAL в Вас уровень Biz, и когда дело доходит до Ваших объектов с небольшой абстракцией можно решить все проблемы, например, если у Вас есть потребительский класс, можно сделать abstaractoin потребительский класс, которые реализуют, основным операциям для взаимодействия с DAL нравится, сохраняют, обновляют и получают данные и в другом классе, который наследовался, класс абстракции переопределяют реализацию методов базового класса для встречи проверки Бизнеса и так далее.
По-моему:
Уровень доступа к данным (DAL) должен управлять на POCOs (Простые объекты CLR) использованием операций, таких как: SaveNewsItem ( NewsItemDAO newsItemDAO ). POCOs являются Ваши ДАО (Объекты Доступа к данным).
Бизнес-Слой должен содержать логику для преобразования Объекта доступа к данным (DAO) в богатый бизнес-объект, который является, вероятно, просто ДАО плюс некоторые операции, а также любое художественное оформление/обогащение.
DAL должен не знать вообще о Слое Бизнес-логики. Это, в теории, должно быть в состоянии быть названным от любого клиента. Например, что, если Вы хотели разделить DAL от приложения и развернуть его как отдельный сервис, представляющий себя через WCF?
, Как упомянуто, операции DAL, например, SaveNewsItem должны быть быть полученными доступ ФИЛИАЛОМ через интерфейсы, возможно, через внедрение зависимости / МОК.