Создание повторноиспользуемых бизнес моделей с помощью технологии Domain       Components (DC)     Денис Гаравский , Frame...
Принцип трех I или     знакомство с Domain ComponentsInterface vs СlassЛегкое комбинирование за счет «множественного насле...
Морфология                 Domain ComponentsИнтерфейс   Интерфейс   ИнтерфейсIPerson     IAccount    ICompany             ...
Доменный компонент (DC)“Это интерфейс, помеченный атрибутомDomainComponentAttribute и определяющийконтракт данных и методо...
Доменная логика (Domain Logic)“Это класс, помеченный атрибутомDomainLogicAttribute и определяющий поведениевыбранного Doma...
Виды Domain LogicBuilt-in/reserved      Custom/user-definedAfterConstruction       Get_PropertyName   OnLoaded            ...
Виды Domain ComponentsПо типу хранения данных:• Persistent• Non-PersistentПо типу регистрации в приложении:• Entities (чер...
Non-Persistent DC• Удобны когда компоненту не требуется  отдельная таблица для хранения своих  данных, а используется табл...
Shared Parts DC• Сервисные persistent компоненты, которые  агрегируются более чем одним доменным  компонентом, зарегистрир...
Попробуем «сахар» на вкус...• Сравним создание моделей с XPO и DC• Посмотрим на созданные таблицы в БД• «Вскроем» внутренн...
Плюсы (+)• Возможность создать самодостаточные  бизнес компоненты или библиотеки, и,  протестировав единожды, использовать...
Минусы (-)• Дополнительная абстракция ухудшает  понимание• Отсутствие тотального контроля за  создаваемой БД  – Не лучшее ...
Хотите узнать больше?• DevExpress - www.devexpress.com• XAF - www.devexpress.com/xaf• DC - http://bit.ly/XicRxa• dennis@de...
Upcoming SlideShare
Loading in …5
×

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

1,175 views
998 views

Published on

Материалы со встречи: http://getdev.net/Event/xaf-reuse

Задумывались ли вы когда-нибудь, что с переходом от SQL к DataSet, а затем и к ORM типа Entity Framework развитие технологий для доступа и управления данными приостановилось? Что еще нового можно придумать к уже привычному оперированию записями таблиц БД как объектами CRL и при этом поднять удобство разработчика на следующий уровень? На этот и другие вопросы попробует дать ответ доклад о технологии Domain Components (часть DevExpress eXpressApp Framework), которая облегчает создание повторно используемых бизнес моделей за счет легкого комбинирования путем использования интерфейсов вместо классов (это позволяет вам эмулировать "множественное наследование" в C# и VB.NET), а также свободы от особенностей конкретной ORM.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,175
On SlideShare
0
From Embeds
0
Number of Embeds
320
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Задумывались ли вы когда-нибудь, что с переходом от SQL к DataSet, а затем и к ORM типа EntityFramework развитие технологий для доступа и управления данными приостановилось? Что еще нового можно придумать к уже привычному оперированию записями таблиц БД как объектами CRL и при этом поднять удобство разработчика на следующий уровень? На этот и другие вопросы попробует дать ответ доклад о технологии DomainComponents (часть DevExpress eXpressApp Framework), которая облегчает создание повторно используемых бизнес моделей за счет легкого комбинирования путем использования интерфейсов вместо классов (это позволяет вам эмулировать "множественное наследование" в C# и VB.NET), а также свободы от особенностей конкретной ORM.
  • Перед тем как я начну рассказывать про технологию DC, я хотел бы задать вам вопрос: если в зале люди, когда-нибудь использовавшие множественное наследование? (поднимают руки 1-10 человек). Ну же бывшие Си++ сники, где же вы, возможно это будет вам интересно. Что же такое DC? Вкратце, это технология, которая облегчает создание повторно используемых бизнес моделей и базируется на трех китах, трех IВы возможно уже слышали о принципе 6ти рукопожатий ну и наверняка используете каждый день технологию 3G, поэтому вам будет интересно узнать что еще за 3I.Interface vs Class:Использование интерфейсов вместо классов. Это означает, что вы можете легко комбинировать ваши бизнес модели за счет «множественного наследования». Я взял это в кавычки, потому что на самом деле это всего лишь эмуляция, хоть и полностью прозрачная для пользователя. Чуть позже я расскажу, почему.Independence from ORM: Бизнес модель НЕ зависит от особенностей конкретной ORM. Это значит, что вы пишете чистый код, который легко протестировать ввиду отсутствия каких-либо зависимостей на окружение.Inversion of Control (IoC): Все знают, что интерфейсы в отличие от классов, не могут содержать реализаций. Тогда возникает законный вопрос: где же должна жить бизнес логика, ведь согласно Мартину Фаулеру полноценная, не-анемичная бизнес модель должна состоять из данных и поведения. В DC вы определяете логику модели в отдельном сервисном классе, где вы зависите только от интерфейсов нужных моделей и возможно контекста базы данных. На базе интерфейсов и связанных с ними классов-логик во время исполнения компонуются реальные бизнес объекты через адаптерили сборщик дляконкретной ORM.
  • Возвращаясь к депенденсиинжекшин, если мы рассмотрим если мы посмотрим что представляет из себя ICRMCustomerво время исполнения, то мы увидим, что это будет обычный XPO объект, который будет поддерживать интерфейсы IAccount, ICompany. В то же время, для каждого из этих интерфейсов должен был быть создан свой реальный ХПО объект. Таким образом, ICRMCustomerфизически будет представлять из себя композицию объектов, к которым будут делегироваться вызовы согласно поддерживаемым контрактам.
  • Основное преимущество 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.
  • Создание повторно используемых бизнес моделей с помощью технологии Domain Components

    1. 1. Создание повторноиспользуемых бизнес моделей с помощью технологии Domain Components (DC) Денис Гаравский , Frameworks Team, DevExpress dennis@devexpress.com | @DennisGaravsky | www.devexpress.com
    2. 2. Принцип трех I или знакомство с Domain ComponentsInterface vs СlassЛегкое комбинирование за счет «множественного наследования»Independence from ORMПростое тестирование и сопровождениеInversion of Control (IoC)Бизнес логика добавляется через Dependency InjectionКомпоновка в реальные объекты выбранной ORM происходит вовремя исполнения (runtime)
    3. 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. 4. Доменный компонент (DC)“Это интерфейс, помеченный атрибутомDomainComponentAttribute и определяющийконтракт данных и методов работы с ними”[DomainComponent]public interface IMyDcInterface { <data type> DataN {get; <set;>} <return type> MethodN (<parameters>); //other data and method contracts…}
    5. 5. Доменная логика (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… }}
    6. 6. Виды Domain LogicBuilt-in/reserved Custom/user-definedAfterConstruction Get_PropertyName OnLoaded Set_PropertyName OnSaving BeforeChange_PropertyName OnSaved AfterChange_PropertyName OnDeleting MethodName OnDeleted
    7. 7. Виды Domain ComponentsПо типу хранения данных:• Persistent• Non-PersistentПо типу регистрации в приложении:• Entities (через метод RegisterEntity)• Shared Parts(через метод RegisterSharedPart)
    8. 8. Non-Persistent DC• Удобны когда компоненту не требуется отдельная таблица для хранения своих данных, а используется таблица производного компонента• Можно использовать как маску или шаблон данных при создании произвольных компонентов• Такой компонент нельзя использовать для запросов к базе, так для него нет таблицы
    9. 9. Shared Parts DC• Сервисные persistent компоненты, которые агрегируются более чем одним доменным компонентом, зарегистрированным как Entity в приложении• Нужны во избежание коллизий между значениями ключей, используемых в разных Entities• Требуют особой регистрации через метод RegisterSharedPart и накладывают следующие ограничения на ключ базового класса: – должен быть публичным mutable свойством Oid и иметь тип System.Guid
    10. 10. Попробуем «сахар» на вкус...• Сравним создание моделей с XPO и DC• Посмотрим на созданные таблицы в БД• «Вскроем» внутренности DC с помощью ReflectorПримеры в «студию»!
    11. 11. Плюсы (+)• Возможность создать самодостаточные бизнес компоненты или библиотеки, и, протестировав единожды, использовать их в различных проектах• Синтаксический сахар в виде «множественного наследования» интерфейсов, позволяющий легко комбинировать их, производя новые бизнес компоненты, агрегирующие данные и поведение своих запчастей• Легкое тестирование и разработка ввиду отсутствие завязок на конкретный ORM
    12. 12. Минусы (-)• Дополнительная абстракция ухудшает понимание• Отсутствие тотального контроля за создаваемой БД – Не лучшее решение для существующих схем – Наличие обязательных сервисных таблиц и ограничений на тип ключевого поля• Чрезмерное увлечение «множественным наследованием» может привести к потере производительности
    13. 13. Хотите узнать больше?• DevExpress - www.devexpress.com• XAF - www.devexpress.com/xaf• DC - http://bit.ly/XicRxa• dennis@devexpress.comВопросы в студию!

    ×