Создание повторно используемых бизнес моделей с помощью технологии Domain

Components (DC)

Денис Гаравский , Frameworks Team, DevExpress

dennis@devexpress.com | @DennisGaravsky | www.devexpress.com

Принцип трех I илизнакомство с Domain

Components

Interface vs СlassЛегкое комбинирование за счет «множественного наследования»

Independence from ORMПростое тестирование и сопровождение

Inversion of Control (IoC)Бизнес логика добавляется через Dependency InjectionКомпоновка в реальные объекты выбранной ORM происходит во время исполнения (runtime)

Морфология Domain Components

ПроизводныйDomain

Component

ИнтерфейсIPerson

ИнтерфейсIAccount

Класс логикиIPerson

Класс логикиIAccount

ИнтерфейсICompany

Класс логикиICompany

[DomainComponent]interface ICRMCustomer : IAccount, ICompany, INotes, IPhones, ... , ... {...}XafTypesInfo.Instance.RegisterEntity(«MyAppCustomer", typeof(ICRMCustomer));

Доменный компонент (DC)

“Это интерфейс, помеченный атрибутом DomainComponentAttribute и определяющий контракт данных и методов работы с ними”

[DomainComponent]public interface IMyDcInterface { <data type> DataN {get; <set;>} <return type> MethodN (<parameters>); //other data and method contracts…}

Доменная логика (Domain Logic)“Это класс, помеченный атрибутом DomainLogicAttribute и определяющий поведение выбранного Domain Component интерфейса”

[DomainLogic(typeof(IMyDcInterface))]public class MyDcInterfaceLogicClass { public <return type> MethodName( <IDcInterface instance>, <IObjectSpace dbContext>, <other optional parameters> ) { //some cool implementation… }}

Виды Domain Logic

Built-in/reserved Custom/user-defined

AfterConstruction Get_PropertyName

OnLoaded Set_PropertyName

OnSaving BeforeChange_PropertyName

OnSaved AfterChange_PropertyName

OnDeleting MethodName

OnDeleted

Виды Domain Components

По типу хранения данных:• Persistent

• Non-Persistent

По типу регистрации в приложении:• Entities (через метод RegisterEntity)• Shared Parts(через метод RegisterSharedPart)

Non-Persistent DC

• Удобны когда компоненту не требуется отдельная таблица для хранения своих данных, а используется таблица производного компонента

• Можно использовать как маску или шаблон данных при создании произвольных компонентов

• Такой компонент нельзя использовать для запросов к базе, так для него нет таблицы

Shared Parts DC• Сервисные persistent компоненты, которые

агрегируются более чем одним доменным компонентом, зарегистрированным как Entity в приложении

• Нужны во избежание коллизий между значениями ключей, используемых в разных Entities

• Требуют особой регистрации через метод RegisterSharedPart и накладывают следующие ограничения на ключ базового класса: – должен быть публичным mutable свойством Oid и

иметь тип System.Guid

Попробуем «сахар» на вкус...

• Сравним создание моделей с XPO и DC

• Посмотрим на созданные таблицы в БД

• «Вскроем» внутренности DC с помощью

Reflector

Примеры в «студию»!

Плюсы (+)• Возможность создать самодостаточные

бизнес компоненты или библиотеки, и, протестировав единожды, использовать их в различных проектах

• Синтаксический сахар в виде «множественного наследования» интерфейсов, позволяющий легко комбинировать их, производя новые бизнес компоненты, агрегирующие данные и поведение своих запчастей

• Легкое тестирование и разработка ввиду отсутствие завязок на конкретный ORM

Минусы (-)

• Дополнительная абстракция ухудшает понимание

• Отсутствие тотального контроля за создаваемой БД– Не лучшее решение для существующих схем– Наличие обязательных сервисных таблиц и ограничений

на тип ключевого поля

• Чрезмерное увлечение «множественным наследованием» может привести к потере производительности

Хотите узнать больше?

• DevExpress - www.devexpress.com

• XAF - www.devexpress.com/xaf

• DC - http://bit.ly/XicRxa

• dennis@devexpress.com

Вопросы в студию!