CQRS: какой бэкэнд использовать для моего View-Store? - PullRequest
4 голосов
/ 31 марта 2012

Моя архитектура на основе CQRS в настоящее время имеет 4 компонента. Это скорее прототип, поэтому в камне еще ничего не установлено.

  • CommandProcessor : получает команды, выполняет их и т. Д. (Duh ^^), публикует события. На основе Azure
  • ViewProcessor : получает запросы на просмотр, отвечает с видом. Подписка на события для обновления просмотра магазина. Является На основе Azure
  • WebClient : веб-портал, насыщенный AJAX, отправляет команды и запросы (json-) просмотров. На основе Azure
  • DesktopClient : Не так много, чтобы сказать, также отправляет команды и запрашивает представления (не определены, если JSON или некоторые другой формат). Очевидно, не на лазурной основе.

Мой оригинальный подход заключался в использовании InMemory-Viewstore. Виртуальные машины Azure имеют довольно много доступной памяти, и я действительно не видел необходимости добавлять сложность Blob-Storage и т. Д. Кроме того, я пытаюсь минимизировать задержку выполнения команды, чтобы хотя бы частично обойти всю проблему асинхронного интерфейса, чтобы я мог (при необходимости) моделировать синхронный интерфейс с (быстрыми) обратными вызовами (надеюсь, это предложение имело смысл ^^) .

При создании веб-клиента я заметил потенциальный недостаток в моем плане. URL-адрес ViewProcessor, очевидно, отличается от URL-адреса WebClient, поэтому запросы json не будут выполняться из-за политики Same-Origin-Policy. Альтернативы / обходные пути, такие как jsonp, не кажутся такими привлекательными, потому что они не решают проблему безопасности. Реализация запросов ajax для целевого WebClient была бы вариантом, но тогда у меня была бы избыточная функциональность (view-store как в webclient, так и в viewprocessor).

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

    Client --command-- CommandProcessor
    CommandProcessor --event-- ViewProcessor
    ViewProcessor --view-- Blob
    (ViewProcessor or CommandProcessor) --notification-- Client
    Blob --view-- Client

Этот сценарий будет иметь небольшую задержку: |

1 Ответ

1 голос
/ 18 апреля 2012

Я бы снова посмотрел вариант хранения BLOB-объектов.Мы храним объекты сериализованного представления в хранилище BLOB-объектов, и это очень быстро и стабильно.Есть ли какой-то аспект хранения BLOB-объектов, который вас беспокоит?

Erick

...