Схема загрузки бизнес-объекта
В проекте, над которым я работаю, используется многоуровневая архитектура. Наши слои следующие:
- Доступ к данным
- Бизнес-логика
- Субъекты бизнеса
- Презентация
Бизнес-логика вызывает уровень доступа к данным, а уровень представления вызывает уровень бизнес-логики, и все они ссылаются на бизнес-объекты.
Наши бизнес-объекты по существу соответствуют нашей модели данных 1-1. Для каждой таблицы у нас есть класс. Первоначально, когда была разработана структура, не рассматривалось управление отношениями «главный-элемент» или «потомок-родитель». Таким образом, вся бизнес-логика, доступ к данным и бизнес-объекты ссылались только на одну таблицу в базе данных. Как только мы начали разработку приложения, быстро стало очевидно, что отсутствие этих отношений в нашей объектной модели сильно вредит нам.
Все ваши слои (включая базу данных) генерируются из внутренней базы данных метаданных, которую мы используем для работы нашего собственного генератора кода.
Вопрос в том, как лучше всего загрузить или отложить загрузку отношений в наших сущностях. Например, предположим, что у нас есть класс людей, который имеет отношение «главный-дочерний» к таблице адресов. Это отображается в бизнес-сущности как свойство коллекции Addresses в объекте Person. Если у нас есть однозначное отношение, это будет отображаться как свойство единой сущности. Как лучше всего заполнить и сохранить объекты отношений? Наши бизнес-объекты не знают об уровне бизнес-логики, поэтому это не может быть выполнено внутренне при вызове свойства.
Я уверен, что для этого есть какой-то стандартный шаблон. Какие-либо предложения?
Также есть одно предостережение: уровень DataAcess использует отражение для построения наших сущностей. Хранимые процедуры возвращают один результат на основе одной таблицы, и, используя отражение, мы заполняем наш бизнес-объект, сопоставляя имена свойств с именами столбцов. Так что сделать присоединение будет сложно.
Ответы 3
На каком языке ты говоришь? Вы описали именно то, что Entity Framework делает в .Net. Но вы не указали, какой язык вы использовали, и я предполагаю, что вы не хотите переписывать какой-либо свой слой данных.
Подход, который я использовал в прошлом, состоит в том, чтобы сделать тип контейнера достаточно умным, чтобы получать требуемые объекты. например:
public class Relation<T>
{
private T _value;
private void FetchData()
{
if ( LoadData != null ) {
LoadDataEventArgs args = new LoadDataEventArgs(typeof(T), /* magic to get correct object */);
LoadData(this, args);
_value = (T)args.Value;
}
}
public event EventHandler<LoadDataEventArgs> LoadData;
public T Value {
get {
if ( _value == default(T) )
FetchData();
return _value;
}
set { /* Do magic here. */ }
}
}
Затем вы объявляете это в своей сущности, например:
[RelationCriteria("ID", EqualsMyProperty = "AddressID")]
public Relation<Address> Address {
get; set;
}
И загрузчик типа, который объявляет свойство Address, должен добавить обработчик к событию LoadData.
Подобный класс реализует IList, чтобы дать вам отношение «один ко многим».
Это интересный подход, но разве он не связывает мои бизнес-объекты с моими DAL или BLL?
Я настоятельно рекомендую посмотреть книгу Фаулера Паттерны архитектуры предприятия. Есть несколько различных подходов к решению такого рода проблем, которые он красиво обрисовывает, включая отношения сущностей.
Одним из наиболее привлекательных элементов может быть шаблон Unit Of Work, который по сути является сборщиком, который наблюдает за действиями, выполняемыми над вашими объектами, и после того, как вы закончите свое действие, он группирует соответствующие вызовы базы данных и отправляет запрос в база данных. Этот шаблон - одна из центральных концепций, используемых NHibernate, который использует объект, реализующий IDisposable, чтобы сигнализировать об окончании «работы». Это позволяет вам обернуть ваши действия в using, а единица работы будет выполнять действия за вас.
Обновлено: дополнительная информация
Этот - это ссылка на базовую структуру классов Unit of Work ... на самом деле не самая захватывающая вещь в мире. Фаулер предоставляет более подробную информацию в своей книге, некоторые из которых вы можете увидеть в здесь. Вы также можете посмотреть на объект Session из NHibernate как на возможную реализацию (я смог отследить интерфейс ISession ... не уверен, где находится реализация)
Надеюсь это поможет.
ckramer - Можете ли вы взять информацию откуда-нибудь и разместить ее здесь о том, как выглядит этот шаблон? Тогда я отмечу тебя как ответившую.
Фреймворк сущности был / не вариант. Мы используем vb.net. Меня интересует подход с использованием методов расширения, но это было бы сложно, учитывая, что мы привязываем данные в WPF.