Создание повторно используемых бизнес моделей с помощью технологии Domain Components
•Download as PPTX, PDF•
0 likes•1,451 views
Материалы со встречи: http://getdev.net/Event/xaf-reuse Задумывались ли вы когда-нибудь, что с переходом от SQL к DataSet, а затем и к ORM типа Entity Framework развитие технологий для доступа и управления данными приостановилось? Что еще нового можно придумать к уже привычному оперированию записями таблиц БД как объектами CRL и при этом поднять удобство разработчика на следующий уровень? На этот и другие вопросы попробует дать ответ доклад о технологии Domain Components (часть DevExpress eXpressApp Framework), которая облегчает создание повторно используемых бизнес моделей за счет легкого комбинирования путем использования интерфейсов вместо классов (это позволяет вам эмулировать "множественное наследование" в C# и VB.NET), а также свободы от особенностей конкретной ORM.
Recommended
More Related Content
Similar to Создание повторно используемых бизнес моделей с помощью технологии Domain Components
Similar to Создание повторно используемых бизнес моделей с помощью технологии Domain Components (20)
More from GetDev.NET
More from GetDev.NET (20)
Создание повторно используемых бизнес моделей с помощью технологии 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. Доменная логика (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. Виды 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
- Задумывались ли вы когда-нибудь, что с переходом от 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.