Схема загрузки бизнес-объекта

В проекте, над которым я работаю, используется n-уровневая архитектура. Наши слои следующие:

  • Доступ к данным
  • Бизнес-логика
  • Субъекты хозяйствования
  • Презентация

Бизнес-логика вызывает уровень доступа к данным, а уровень представления вызывает уровень бизнес-логики, и все они ссылаются на бизнес-объекты.

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

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

Вопрос в том, как лучше всего загрузить или отложить загрузку отношений в наших сущностях. Например, предположим, что у нас есть класс людей, который имеет отношение «главный-дочерний» к таблице адресов. Это отображается в бизнес-сущности как свойство коллекции Addresses в объекте Person. Если у нас есть взаимно-однозначные отношения, это будет отображаться как свойство единой сущности. Как лучше всего заполнить и сохранить объекты отношений? Наши бизнес-объекты не знают об уровне бизнес-логики, поэтому это невозможно сделать внутренне, когда свойство вызывается.

Я уверен, что для этого есть какой-то стандартный шаблон. Какие-либо предложения?

Также есть одно предостережение: уровень DataAcess использует отражение для построения наших сущностей. Хранимые процедуры возвращают один результат на основе одной таблицы, и, используя отражение, мы заполняем наш бизнес-объект, сопоставляя имена свойств с именами столбцов. Так что присоединиться будет сложно.


.net vb.net n-tier-architecture
person Community    schedule 01.10.2008    source источник

Ответы (3)


arrow_upward
2
arrow_downward

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

Одним из наиболее привлекательных элементов будет шаблон Unit Of Work, который, по сути, является сборщиком, который наблюдает за действиями, выполняемыми над вашими объектами, и после того, как вы закончите свое действие, он группирует соответствующие вызовы базы данных и отправляет запрос в база данных. Этот шаблон является одной из центральных концепций, используемых NHibernate, который использует объект, реализующий IDisposable для сигнализировать об окончании «работы». Это позволяет вам обернуть ваши действия в using, а единица работы будет выполнять действия за вас.

Изменить: дополнительная информация

Это ссылка на базовую структуру классов Единицы работы ... не совсем самая захватывающая вещь в мире. Фаулер предоставляет более подробную информацию в своей книге, некоторые из которых вы можете увидеть в здесь. Вы также можете рассмотреть объект Session из NHibernate как возможную реализацию (мне удалось отследить ISession interface ... не знаю, где находится реализация)

Надеюсь это поможет.

person ckramer    schedule 01.10.2008
comment
ckramer - Можете ли вы взять информацию откуда-нибудь и разместить ее здесь о том, как выглядит этот шаблон? Тогда я отмечу тебя как ответившую. - person Micah; 01.10.2008

arrow_upward
1
arrow_downward

Подход, который я использовал в прошлом, заключается в том, чтобы сделать тип контейнера достаточно умным, чтобы получать требуемые объекты. например:

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, чтобы дать вам отношение «один ко многим».

person Andrew Kennan    schedule 01.10.2008
comment
Это интересный подход, но разве он не связывает мои бизнес-объекты с моими DAL или BLL? - person Micah; 01.10.2008

arrow_upward
0
arrow_downward

На каком языке ты говоришь? Вы описали именно то, что Entity Framework делает в .Net. Но вы не указали, какой язык вы использовали, и я предполагаю, что вы не хотите переписывать какой-либо свой слой данных.

person Vyrotek    schedule 01.10.2008
comment
Фреймворк сущности был / не вариант. Мы используем vb.net. Меня интересует подход с использованием методов расширения, но это было бы сложно, учитывая, что мы привязываем данные в WPF. - person Micah; 01.10.2008