Как прозрачно обрабатывать несколько хранилищ

Question

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

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

Мы используем NHibernate для всех наших потребностей в DAL, и, на мой взгляд, эта репликация данных действительно является проблемой постоянства - поэтому я подхватил реализацию PoC с помощью EventListener (как PostInsert, так и PostUpdate), который проверяет, если объект имеет тип X, и любое из полей [Y..Z] было изменено, обновите веб-сервис с новым состоянием.

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

Это ужасная идея, которая пригласит хищников в мою базу данных в неподходящее время? Это абсолютно разумно делать с EventListener? Является ли это полезным решением для не совсем идеальной ситуации, с которой мы можем просто обойтись и двигаться навсегда испорченными? Если мы будем солдатами на этом пути, есть ли какие-то ошибки, о которых мне следует опасаться в конвейере событий?

Answer 1

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

Примерно так:

    public class OperationContainer
    {
    public Operation Operation; //what ever operations you need CRUD, or some specific
    public object Data; //your entity, business object or whatever
    }

    public class MyMailService
    {
    public SendMail (MailBusinessObject data)
    {
    DataAcceessLair<MailBusinessObject>.Persist(data);
    OperationContainer operation = new OperationContainer(){Operation=insert, Data=data};
    DataAcceessLair<OperationContainer>.Persist(operation);
    }
    }

    public class Updater
    {
    Timer EverySec;
    public void OnEverySec()
    {
    var data = DataAcceessLair<OperationContainer>.GetFirstIn(); //FIFO
    var webServiceData = WebServiceData.Converr(data); // do the logic to prepare data for WebService
try
{
    new WebService().DoSomething(data);
DataAcceessLair<OperationContainer>.Remove(data);
}
    }
    }

Это на самом деле довольно близко к концепции умного клиента - технически не логично. Взгляните на книгу: доменное управление .NET с C #: решение проблем - проект, решение, глава 10. Или посмотрите на исходный код из книги, он довольно близок к вашей ситуации: http://dddpds.codeplex.com/