Единица работы с несколькими источниками данных?

Question

Возможно (даже возможно), что я просто не полностью понимаю идею «единицы работы». В принципе, я рассматриваю это как своего рода широкую транзакцию, используемую в объектно-ориентированной среде. Запустите единицу работы, взаимодействуйте с объектами, зафиксируйте или откат. Но как это разрушается до фактических транзакций в хранилищах данных за этими объектами?

В системе с единой БД и ORM (например, NHibernate) это легко. Транзакция может поддерживаться через ORM. Но как насчет системы, в которой пользовательские модели домена скрывают многие несопоставимые источники данных? И не все эти источники данных являются реляционными базами данных? (Здесь много сделано в файловой системе.)

В настоящее время я придерживаюсь идеи, что «вы просто не можете поддерживать транзакцию через базу данных SQL2005, базу данных SQL2000, базу данных DB2 и файловая система все в одной и той же «атомной» бизнес-операции ». Так что на данный момент разработчики в команде (которые обычно работают независимо друг от друга) несут ответственность за ведение транзакций вручную в коде. Каждая БД может иметь на ней правильные транзакции, но бизнес-операция в целом проверяется вручную и балансирует каждый важный шаг на пути.

Однако с возрастающей сложностью в области и стандартным оборотом разработчиков этот подход будет становиться все более сложным и подверженным ошибкам с течением времени.

Есть ли у кого-нибудь какие-либо советы или примеры того, как лучше всего разрешить такой домен, или как он был ранее рассмотрен? Фактический «домен» в этом случае все еще очень в зачаточном состоянии, развиваясь как прототип в один день, расширяя и потребляя/заменяя большую экосистему разрозненных устаревших приложений. Таким образом, есть много возможностей для перепроектирования и повторного факторинга.

Для справки, 10 000-футовый взгляд на дизайн, к которому я в настоящее время нацелен, - это большая коллекция небольших, как можно глухих, клиентских приложений, вызывающих центральное обслуживание на основе сообщений. Услуга - это вход в «ядро домена» и может рассматриваться как одно большое приложение в стиле MVC. Запросы принимаются к сервису (так же, как «действия»), которые собираются обработчиками (подобно «контроллерам»). Там идет процедура. Они взаимодействуют с моделями, которые содержат все бизнес-правила. Модели публикуют события, в которых слушатели («службы», эта часть все еще облачно в дизайне и могут быть улучшены) выбирают и обрабатывают, взаимодействуя с репозиториями (база данных x, база данных y, файловая система, электронная почта, любой внешний ресурс). Соответственно все инъекции в зависимости от употребления алкоголя.

Извините за все многословие :) Но если у кого-нибудь есть какие-либо советы, я бы хотел его услышать. Даже (особенно), если этот совет «ваш дизайн плох, попробуйте это вместо этого ...» Спасибо!

Answer 1

Я ранее работал над системой, которая могла бы выполнить это, и это довольно просто. Поскольку проект находится на ранних стадиях, возможно, это может быть полезной для вас информацией. К сожалению, у меня больше нет доступа к коду, но мне все еще удобно описывать, как он работает.

Что я сделал, были созданы мои репозитории с использованием общей реализации шаблона репозитория. Тип базового репозитория всегда будет ссылкой на службы и UoW. Для обсуждения мы будем называть его BaseRepository. «T» будет ограничено реализациями IEntity, которые обозначают объект домена. Из BaseRepository я создал еще один набор базовых классов для компоновки, таких как SqlBaseRepository, XmlBaseRepository и т. Д.

UoW только заботится о том, что что-то типа BaseRepository, в котором будет существовать базовая функциональность. Будет представлен базовый CUD (CRUD), обеспечивающий эквиваленты для создания, обновления и удаления.То, что каждый из них будет делать, - это создать делегат и поместить его в очередь внутри UoW, а также передать информацию о том, какой тип транзакции он будет, и соответствующие данные, необходимые для его завершения. UoW начнет поддерживать список того, какие хранилища должны будут участвовать в транзакции, но все равно не волнует, какой тип он был. Исключительно, ожидание здесь похоже на завершение транзакции.

В BaseRepository определен абстрактный метод, называемый как .ApplyChange(). После того, как в UoW был вызван .Commit(), он создаст TransactionScope() и начнет вызывать delagates в списке, передав информацию в .ApplyChange(). Фактическая реализация .ApplyChange() существует в конкретной базе репозитория, то есть в SqlRepositoryBase и т. Д., А также может быть переопределена реализацией.

Куда он оказался хитрым, для меня, по крайней мере, катился назад. Я занимался только одной базой данных, но иногда делал изменения на основе файлов. Я добавил метод .RevertChange() и начал отслеживать исходное состояние и измененные состояния, чтобы в принципе применить обратную-дельта, чтобы вернуться туда, где я был в стеке файлов.

Желаю, чтобы я мог быть более конкретным в реализации, но прошло уже больше года с тех пор, как я увидел код сейчас. Я могу вам сказать, что основа для исходного кода была взята из книги, .NET Domain-Driven Design with C#: Problem - Design - Solution, Тимом Маккарти. Большая часть моей реализации репозитория была основана на его примерах, причем большая часть моей настройки включалась в UoW и их реализацию.

Я надеюсь, что это поможет, несколько! :-)