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

Question

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

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

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

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

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

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

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

Answer 1

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

То, что я сделал, было построено свои репозитории, используя общую реализацию шаблона репозитория. Тип базового репозитория всегда будет ссылками услуг и UOW. Для дискуссии мы назовем его басрипозиторием. «T» будет ограничен реализациями IEntity, которые обозначали объект домена. Из базовоспорития я создал еще один набор базовых классов для композита, таких как SQLBaserePository, XMLBasePository и т. Д.

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

Основной композидитор определил абстрактный метод, называемый чем-то вроде .applychange (). Когда-то .Commit () был вызван на UOW, он создал бы транзакиcope () и начать вызов delagates в списке, передавая информацию в .applychange (). Фактическая реализация .applyChange () существует в конкретной основе хранилища, то есть SQLReposityBase и т. Д. И может быть переопределена путем реализации.

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

Я хотел бы, чтобы я мог бы быть более конкретным в реализации, но было более года, так как я видел код сейчас. Я могу сказать вам, что основа для оригинального кода была перенесена из книги, .NET Domain-Domain Design с C #: Проблема - Дизайн - решение, Тим Маккарти. Большое количество моего внедрения хранилища основано на его примерах, с большим большинством моей настройки, приходящей в Уоси и их реализацию.

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