Полное название проекта: система поддержки модели предметной области (Domain Model Support System).
Цель проекта: создание вспомогательной библиотеки классов, которая делает взаимодействие объектов предметной области приложения с источником данных максимально простым и достаточно производительным.
Задачи проекта:
— реализация отображения объектов предметной области приложения на источник данных (реализация CRUD операций);
— предоставление удобных инструментов для построения запросов к источнику данных и преобразование результатов выполнения этих запросов в объекты предметной области приложения;
— определение основных классов, необходимых для построения богатой модели предметной области и реализации бизнес-логики приложения;
— возможность простой интеграции в клиент-серверные приложения и web-службы с любым количеством пользователей, использующих различные виды клиентов.
Введение
BusinessObject bo = new BusinessObject();
bo.Name = "My New Business Object";
bo.Save();
С точки зрения программирования бизнес-логики приложения такой код можно назвать идеальным: просто и предельно понятно. При этом особенно приятно осозновать тот факт, что после вызова метода "Save" со стороны программиста абсолютно не требуется прилагать какие-либо дополнительные усилия для проектирования и реализации слоя источника данных, так как уже существует вспомогательная библиотека классов, которая решает эти проблемы за него …
Перспектива:
разработка приложения Domain Builder для визуального проектирования модели предметной области, основанного на результатах данного проекта.
P.S.
Имеется полный текст статьи с описанием проекта, работающий прототип проекта и диаграмма классов на UML.
Все это может получить любой желающий по запросу на мой e-mail: dima_zhichkin@mail.ru
Re: [b]Domain System[/b] - Domain Driven Design Support Syst
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Dimsen, Вы писали:
AVK>Чем это лучше DLINQ?
Абсолютно ничем
Разве что возможностью модифицировать исходники
На самом деле DLinq использует сессионную модель кэширования данных,
а мой проект использует глобальную модель (один кэш для всех сессий).
Архитектура DLinq более изящна, ИМХО, а также более практична ...
Кроме этого, ежу понятно, что Microsoft DLinq Project это не Вася Пупкин из Зажопинска
Просто я начал делать проект, когда про DLinq я еще слыхом не слыхивал и нюхом не нюхивал
Просто прочитал книгу Мартина Фаулера и решил реализовать то, что мне больше всего понравилось в книге на практике, ну и поделиться с народом конечно же, а еще очень хотелось вставить фитиль в задницу 1С, чтобы не расслаблялись
Re[3]: [b]Domain System[/b] - Domain Driven Design Support S
Здравствуйте, Dimsen, Вы писали:
D>На самом деле DLinq использует сессионную модель кэширования данных, D>а мой проект использует глобальную модель (один кэш для всех сессий).
И как в такой модели разруливать параллельные транзакции?
Глубокого анализа я не делал, но есть две вещи, которые составляют принципиальную разницу:
1. Так как DLinq по сути своей использует сессионную модель кэширования данных, он имеет возможность возвращать ссылку на уже загруженный объект, в то время как Domain System использует модель глобального кэширования объектов предметной области и вынужден возвращать пользователям из различных сессий клоны кэшированных объектов. Тем не менее, централизованный кэш объектов упрощает управление объектами и может рализовывать, например, разрешение конфликтов совместного доступа к объектам или проверку прав доступа к ним и т.д.
2. Объекты DLinq не могут иметь многозначных полей типа EntityRef или EntitySet. Т.е., если, например, мы имеем класс "Накладная", где присутствует свойство "Контрагент", значением которого может являться либо объект класса "Юридическое лицо", либо "Физическое лицо", то DLinq не позволит нам такой вольности ... Проект Domain System в данный момент не реализует такой возможности, но это вполне не сложно сделать в его рамках и это присутствует в дальнейших планах его развития.
3. DLinq управляет объектами при помощи коллекций типа Table<EntityType> и класса DataContext — очень продуктивный и изящный подход, но нет возможности управлять поведением объекта вне этих рамок. Domain System не управляет поведением объектов в принципе — объекты сами отслеживают свое состояние и ведут себя так, как им удобно.
Больше пока мыслей нет, если будут, то добавлю
Re[4]: [b]Domain System[/b] - Domain Driven Design Support S
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Dimsen, Вы писали:
D>>На самом деле DLinq использует сессионную модель кэширования данных, D>>а мой проект использует глобальную модель (один кэш для всех сессий).
AVK>И как в такой модели разруливать параллельные транзакции?
Боюсь я не совсем правильно понимю Ваш вопрос.
Привидите пример, пожалуйста.
Re[4]: [b]Domain System[/b] - Domain Driven Design Support S
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Dimsen, Вы писали:
D>>На самом деле DLinq использует сессионную модель кэширования данных, D>>а мой проект использует глобальную модель (один кэш для всех сессий).
AVK>И как в такой модели разруливать параллельные транзакции?
Если Вы имеете ввиду управление конкурентным доступом к данным (concurency или transaction isolation level), то в данный момент в прототипе реализована модель ADO.NET, где "выигрывает последний", так как сама модель вообще-то работает с отключенными по своей сути данными. Если говорить о пессимистической блокировке данных, тоо можно использовать подход DLinq, где рекомендуется юзать TransactionScope ... Можно еще расширить функциональность классов DataSource и IdentityMap самого проекта Domain System, напрмер наложением блокировок на корневые объекты DomainObject.
В прототипе все это не реализовано для его упрощения, хотя в альфа версии я пытался реализовать и авторизацию доступа к объектам DomainObject и их пессимистические блокировки, но тогда сам прототип становился сложноватым для понимания новичками в этом деле, а цель изначально была показать как такие системы типа 1С, например, реализуются в принципе.
Re[5]: [b]Domain System[/b] - Domain Driven Design Support S
Здравствуйте, Dimsen, Вы писали:
D>Боюсь я не совсем правильно понимю Ваш вопрос. D>Привидите пример, пожалуйста.
Идут две транзакции. Транзакция А меняет объект из кеша. После этого его из кеша подхватывает транзакция Б. В этот момент транзакция А откатывается. Налицо нарушение изоляции.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Dimsen, Вы писали:
D>>Боюсь я не совсем правильно понимю Ваш вопрос. D>>Привидите пример, пожалуйста.
AVK>Идут две транзакции. Транзакция А меняет объект из кеша. После этого его из кеша подхватывает транзакция Б. В этот момент транзакция А откатывается. Налицо нарушение изоляции.
Кажись я уже ответил на этот вопрос, но все же ...
Если говорить о стратегии "последний выигрывает", то, по моему все понятно.
Если говорить о стратегии пессимистической блокировки, то можно на уровне класса IdentityMap реализовать блокировку корневых объектов типа DomainObject (кэшируются только объекты этого типа) для этого и был изначально создан класс MapEntry, чтобы его, если нужно, можно было расширить свойствами типа IsBusy, DomainUser и т.п. Есть конечно же и другие варианты реализации конкурентного достпа к данным, просто я не стал включать все это в простой прототип.
