Образец загрузки бизнес-объекта

Question

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

• доступа к данным
• Business Logic
• Хозяйствующие субъекты
• Презентация

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

Answer 3

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

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