Я просто рассматриваю несколько вариантов архитектуры для стандартных программных систем.Возможно, вы хотели бы поделиться своим мнением.
Система: у нас есть компонент бизнес-логики с базовой базой данных.До сегодняшнего дня этот логический компонент использовался только одним клиентом, и, таким образом, интерфейс и логический уровень и уровень данных были в одном исполняемом файле.(Инструмент A)
Теперь программа обладает такими замечательными функциями, что ее должен использовать другой, уже существующий инструмент (Инструмент B).Инструмент B также должен использовать (или, по крайней мере, отображать) некоторые данные инструмента A, но он также сохраняет свое собственное хранилище данных.Наш подход к решению прост: мы разделяем Инструмент A. Бизнес-логика получает сервисный интерфейс (возможно, веб-сервисы, RESTful или нет).Затем инструмент B может получить доступ к бизнес-логике инструмента A, получить данные, выполнить вычисления, что угодно.
Теперь, если Инструмент B показывает данные Инструмента A, было бы хорошо, если бы он был уведомлен об изменениях данных в Инструменте A. Наш интерфейс сервиса хорош, но односторонняя история (если вы этого не сделаетеделать трюки, такие как держать асинхронные вызовы открытыми, пока не произойдет событие).
Мы видим несколько вариантов:
a.Инструмент B также получает сервисный интерфейс.Когда он запускается, он регистрируется с помощью инструмента A, и инструмент A отправляет события изменения в инструмент B.
b.Инструмент B опрашивает сервис инструмента A на предмет изменений.
c.Мы представляем промежуточное программное обеспечение, где Инструмент A публикует события, и все клиенты могут подписаться на эти события.
Нам не нравится б).Слишком медленно, и инструменту А понадобятся средства для определения изменений для каждого клиента.в) накладные расходы на внедрение нового компонента.а) Будет крепко соединять два инструмента.
Дополнительная информация: У нас будет центральное хранилище данных (+ наш компонент бизнес-логики) на одном компьютере.На других машинах могут быть клиенты (скажем, до 20. Не 100, не 1000, не 10000).Это система от одного поставщика.Мы не должны быть готовы ко многим сторонним инструментам, которые хотят использовать события (это было бы сильным показателем для решения c)).
Вопросы: i) Какие у нас есть варианты кроме a) -c)?II) Какой путь вы бы пошли и почему?