Интерфейс администратора для управления двумя связанными источниками данных - PullRequest
0 голосов
/ 17 декабря 2009

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

Вот пример: есть список языков. Оба приложения - проектные и устаревшие - должны их использовать. Тем не менее, они оба добавляют свое значение. Например, проекту может потребоваться активный / неактивный, а устаревшему понадобится код языка.

Но администратор должен управлять всем - именем языка, активным / неактивным, языковым кодом. При загрузке данные из обеих систем должны объединяться и представляться, а при сохранении данные должны обновляться в обеих системах.

Таким образом, каков наилучший способ представления этих отдельных данных (которые будут использоваться на странице администратора)? Обратите внимание, что я использую ASP.NET MVC / NHibernate.

  1. Как мне управлять устаревшими данными?
    • Подключить ли административную часть к внешнему интерфейсу устаревшей веб-службы - где она в настоящее время имеет только методы GetXXX () - и добавить пропущенные методы C [R] UD?
    • Или, я могу подключиться напрямую к устаревшей базе данных - это возможно, так как я действительно управляю ею.
  2. Где я делю / объединяю данные - на уровне контроллера / службы или на уровне хранилища / данных?
    • На уровне контроллера я сделаю "var viewmodel = new ViewModel {MyData = ..., LegacyData = ...}; Проблема - код перегружен устаревшими проблемами.
    • На уровне данных я сделаю «var model = repository.Get (id)», и модель будет содержать данные из обоих миров, а когда я сделаю «repository.Save (entity)» он обновит оба источника данных - в локальной базе данных будут храниться только поля, специфичные для проекта. Проблемы: а) возможная утечка абстракции б) получение данных из веб-сервиса всегда, когда это необходимо только иногда и обычно только для административной части
      • модификация, используйте ICombinedRepository , которая обеспечит дополнительное разделение / слияние. Проблемы: все еще нужна новая модель или IWithLegacy ...
  3. иметь единый метод "синхронизации"; это удалит устаревшие элементы, отсутствующие в списке элементов проекта, обновит те, которые присутствуют, создаст устаревшие элементы, которые пропущены, и т. д ...

Ну, подведем итоги по основным вопросам:

  • разрабатывать ли я интерфейс CRUD для веб-службы или подключаться напрямую к его базе данных (которая находится под моим полным контролем, так что я могу даже позже решить перенести эту часть веб-службы в основное приложение или использовать ее для основной базы данных)
  • Есть ли у меня отдельные классы для проекта и унаследованных объектов, которые, таким образом, управляются отдельно, или у объектов проекта есть все унаследованные поля, которые прозрачно управляются при сохранении / загрузке?

В любом случае, есть ли полезные советы по управлению в основном дублированными данными из разных источников? Каковы лучшие практики?

В части без прав администратора я хотел бы полностью скрыть понятие устаревших данных. Что я и делаю сейчас, за интерфейсами репозитория. Но для административной части это не так ясно или просто ...

1 Ответ

1 голос
/ 19 декабря 2009

То, что вы здесь описываете, кажется, оправдывает необходимость в антикоррупционном слое. Решения, связанные с этой темой, можно найти здесь: DDD, Антикоррупционный слой, как?

Когда у вас есть два концептуальных ограниченных контекста, но вы используете DDD только для одного из них, в игру вступает антикоррупционный слой. Когда читает из вашего источника данных (выполняет операцию get [R]), антикоррупционный слой преобразует ваши унаследованные данные в пригодные для использования объекты для вашего проекта. Когда записывает в ваш источник данных (выполняя заданную операцию [CUD]), антикоррупционный слой преобразует ваши DDD-объекты в объекты, понятные вашим унаследованным кодом.

Возможность использования существующей веб-службы зависит от того, желаете ли вы изменить существующий код. Придерживаясь СУХОЙ практики, вы не хотите дублировать то, что у вас уже есть. Если вы хотите сохранить веб-службу, вы можете добавить методы CUD в слой защиты от коррупции, не затрагивая устаревшее приложение.

На антикоррупционном уровне вы захотите использовать адаптеры и фасады для объединения отдельных классов для вашего проекта DDD и унаследованного приложения.

Антикоррупционный слой - это именно то место, где вы обрабатываете разбиение и слияние.

Дайте мне знать, если у вас есть какие-либо вопросы по этому поводу, так как это может быть несколько продвинутая тема. Я постараюсь ответить как можно лучше.

Удачи!

...