Downloaded 11 times
![Морфология
Domain Components
Интерфейс Интерфейс Интерфейс
IPerson IAccount ICompany
Производный
Domain
Класс Класс Класс Component
логики логики логики
IPerson IAccount ICompany
[DomainComponent]
interface ICRMCustomer : IAccount, ICompany,
INotes, IPhones, ... , ... {...}
XafTypesInfo.Instance.RegisterEntity(
«MyAppCustomer", typeof(ICRMCustomer));](https://image.slidesharecdn.com/random-130408021946-phpapp02/75/Domain-Components-3-2048.jpg)
![Доменный компонент (DC)
“Это интерфейс, помеченный атрибутом
DomainComponentAttribute и определяющий
контракт данных и методов работы с ними”
[DomainComponent]
public interface IMyDcInterface {
<data type> DataN {get; <set;>}
<return type> MethodN (<parameters>);
//other data and method contracts…
}](https://image.slidesharecdn.com/random-130408021946-phpapp02/75/Domain-Components-4-2048.jpg)
![Доменная логика (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…
}
}](https://image.slidesharecdn.com/random-130408021946-phpapp02/75/Domain-Components-5-2048.jpg)
Uploaded byGetDev.NET
Создание повторно используемых бизнес моделей с помощью технологии Domain Components
Документ описывает создание повторно используемых бизнес-моделей с использованием технологии domain components (DC). Обсуждаются принципы работы с интерфейсами, бизнес-логикой и различными типами доменных компонентов, включая их преимущества и недостатки. Также приводятся примеры использования DC и ссылки на ресурсы для дополнительной информации.
More Related Content
Similar to Создание повторно используемых бизнес моделей с помощью технологии Domain Components
Создание повторно используемых бизнес моделей с помощью технологии Domain Components
- 1. Создание повторно используемых бизнесмоделей с помощью технологии Domain Components (DC) Денис Гаравский , Frameworks Team, DevExpress dennis@devexpress.com | @DennisGaravsky | www.devexpress.com
- 2. Принцип трех Iили знакомство с Domain Components Interface vs Сlass Легкое комбинирование за счет «множественного наследования» Independence from ORM Простое тестирование и сопровождение Inversion of Control (IoC) Бизнес логика добавляется через Dependency Injection Компоновка в реальные объекты выбранной ORM происходит во время исполнения (runtime)
- 3. Морфология Domain Components Интерфейс Интерфейс Интерфейс IPerson IAccount ICompany Производный Domain Класс Класс Класс Component логики логики логики IPerson IAccount ICompany [DomainComponent] interface ICRMCustomer : IAccount, ICompany, INotes, IPhones, ... , ... {...} XafTypesInfo.Instance.RegisterEntity( «MyAppCustomer", typeof(ICRMCustomer));
- 4. Доменный компонент (DC) “Этоинтерфейс, помеченный атрибутом DomainComponentAttribute и определяющий контракт данных и методов работы с ними” [DomainComponent] public interface IMyDcInterface { <data type> DataN {get; <set;>} <return type> MethodN (<parameters>); //other data and method contracts… }
- 5. Доменная логика (DomainLogic) “Это класс, помеченный атрибутом DomainLogicAttribute и определяющий поведение выбранного Domain Component интерфейса” [DomainLogic(typeof(IMyDcInterface))] public class MyDcInterfaceLogicClass { public <return type> MethodName( <IDcInterface instance>, <IObjectSpace dbContext>, <other optional parameters> ) { //some cool implementation… } }
- 6. Виды Domain Logic Built-in/reserved Custom/user-defined AfterConstruction Get_PropertyName OnLoaded Set_PropertyName OnSaving BeforeChange_PropertyName OnSaved AfterChange_PropertyName OnDeleting MethodName OnDeleted
- 7. Виды Domain Components Потипу хранения данных: • Persistent • Non-Persistent По типу регистрации в приложении: • Entities (через метод RegisterEntity) • Shared Parts(через метод RegisterSharedPart)
- 8. Non-Persistent DC • Удобныкогда компоненту не требуется отдельная таблица для хранения своих данных, а используется таблица производного компонента • Можно использовать как маску или шаблон данных при создании произвольных компонентов • Такой компонент нельзя использовать для запросов к базе, так для него нет таблицы
- 9. Shared Parts DC •Сервисные persistent компоненты, которые агрегируются более чем одним доменным компонентом, зарегистрированным как Entity в приложении • Нужны во избежание коллизий между значениями ключей, используемых в разных Entities • Требуют особой регистрации через метод RegisterSharedPart и накладывают следующие ограничения на ключ базового класса: – должен быть публичным mutable свойством Oid и иметь тип System.Guid
- 10. Попробуем «сахар» навкус... • Сравним создание моделей с XPO и DC • Посмотрим на созданные таблицы в БД • «Вскроем» внутренности DC с помощью Reflector Примеры в «студию»!
- 11. Плюсы (+) • Возможностьсоздать самодостаточные бизнес компоненты или библиотеки, и, протестировав единожды, использовать их в различных проектах • Синтаксический сахар в виде «множественного наследования» интерфейсов, позволяющий легко комбинировать их, производя новые бизнес компоненты, агрегирующие данные и поведение своих запчастей • Легкое тестирование и разработка ввиду отсутствие завязок на конкретный ORM
- 12. Минусы (-) • Дополнительнаяабстракция ухудшает понимание • Отсутствие тотального контроля за создаваемой БД – Не лучшее решение для существующих схем – Наличие обязательных сервисных таблиц и ограничений на тип ключевого поля • Чрезмерное увлечение «множественным наследованием» может привести к потере производительности
- 13. Хотите узнать больше? •DevExpress - www.devexpress.com • XAF - www.devexpress.com/xaf • DC - http://bit.ly/XicRxa • dennis@devexpress.com Вопросы в студию!
Editor's Notes
- #2 Задумывались ли вы когда-нибудь, что с переходом от SQL к DataSet, а затем и к ORM типа EntityFramework развитие технологий для доступа и управления данными приостановилось? Что еще нового можно придумать к уже привычному оперированию записями таблиц БД как объектами CRL и при этом поднять удобство разработчика на следующий уровень? На этот и другие вопросы попробует дать ответ доклад о технологии DomainComponents (часть DevExpress eXpressApp Framework), которая облегчает создание повторно используемых бизнес моделей за счет легкого комбинирования путем использования интерфейсов вместо классов (это позволяет вам эмулировать "множественное наследование" в C# и VB.NET), а также свободы от особенностей конкретной ORM.
- #3 Перед тем как я начну рассказывать про технологию DC, я хотел бы задать вам вопрос: если в зале люди, когда-нибудь использовавшие множественное наследование? (поднимают руки 1-10 человек). Ну же бывшие Си++ сники, где же вы, возможно это будет вам интересно. Что же такое DC? Вкратце, это технология, которая облегчает создание повторно используемых бизнес моделей и базируется на трех китах, трех IВы возможно уже слышали о принципе 6ти рукопожатий ну и наверняка используете каждый день технологию 3G, поэтому вам будет интересно узнать что еще за 3I.Interface vs Class:Использование интерфейсов вместо классов. Это означает, что вы можете легко комбинировать ваши бизнес модели за счет «множественного наследования». Я взял это в кавычки, потому что на самом деле это всего лишь эмуляция, хоть и полностью прозрачная для пользователя. Чуть позже я расскажу, почему.Independence from ORM: Бизнес модель НЕ зависит от особенностей конкретной ORM. Это значит, что вы пишете чистый код, который легко протестировать ввиду отсутствия каких-либо зависимостей на окружение.Inversion of Control (IoC): Все знают, что интерфейсы в отличие от классов, не могут содержать реализаций. Тогда возникает законный вопрос: где же должна жить бизнес логика, ведь согласно Мартину Фаулеру полноценная, не-анемичная бизнес модель должна состоять из данных и поведения. В DC вы определяете логику модели в отдельном сервисном классе, где вы зависите только от интерфейсов нужных моделей и возможно контекста базы данных. На базе интерфейсов и связанных с ними классов-логик во время исполнения компонуются реальные бизнес объекты через адаптерили сборщик дляконкретной ORM.
- #4 Возвращаясь к депенденсиинжекшин, если мы рассмотрим если мы посмотрим что представляет из себя ICRMCustomerво время исполнения, то мы увидим, что это будет обычный XPO объект, который будет поддерживать интерфейсы IAccount, ICompany. В то же время, для каждого из этих интерфейсов должен был быть создан свой реальный ХПО объект. Таким образом, ICRMCustomerфизически будет представлять из себя композицию объектов, к которым будут делегироваться вызовы согласно поддерживаемым контрактам.
- #12 Основное преимущество DC в том, что вы можете создать и протестировать самодостаточные бизнескомпоненты только один раз, а потом легко комбинировать их, производя новые компоненты, также содержащие свои данные и поведение.Most likely, each new XAF application you develop is not unique. The most common objects, such as Person, Phone, Address, etc., are always used. The Business Class Library provides you with a set of classes that you will need most frequently. But implementing your own reusable library is not a simple task. With Domain Components, you can easily package an assembly and reference it in your applications. 2. При этом можно полностью поменять поведение производного компонента без рекомпиляции, заменив лишь библиотеку с его запчастями.Since Domain Components are represented by interfaces and not by classes, you can combine several previously defined components into a new one by aggregating the corresponding interfaces. The new Domain Component will expose the properties of all its ancestors and utilize their Domain Logic. Of course you can add new properties and apply additional logic.