2015-05-19 1 views
3

У меня есть три актера для обработки сценария CQRS. ProductWorkerActor обрабатывает командную часть, ProductQueryWorkerActor обрабатывает часть запроса и ProductStateActor обрабатывает государственную часть.Извлечение государственных акторов через артистов-актеров в AKKA

Путь я обработки запроса является использование:

ProductQueryWorkerActor.Ask<ProductState>("give-me-product-state-for-product-1000") 

Код из ProductQueryWorkerActor:

if (message == "give-me-product-state-for-product-1000") 
{ 
    var actor = Context.ActorSelection("akka://catalogSystem/user/productState/1000"); 
    var psDTO = actor.Ask<ProductStateDTO>(message).Result; 
    Sender.Tell(ps); 
} 

Пожалуйста, игнорируйте путь используется для доступа к нему продукции. Он жестко запрограммирован и преднамерен для упрощения чтения кода.

  1. Должен ли я использовать Спросите как я использовал в этом случае, чтобы получить состояние продукта? Является ли Ask названным фьючерсом?

  2. Должен ли я раскрывать состояние как DTO для наружной работы, а не для самого актера?

  3. Для изменения любого состояния продукта, я должен заниматься обработкой сообщений в ProductWorkerActor или ProductStateActor самих? Во втором случае ProductWorkerActor посылает сообщение ProductStateWorker, в ProductStateWorker обрабатывает сообщение, измените состояние и отправить еще одно сообщение ProductWorkerActor, что прошло проверку и изменил состояние.

ответ

4

В случае, если вы используете событие Sourcing с актерами, я советую вам использовать Akka.Persistence. Он обрабатывает разделение актеров для чтения/записи и будет зависеть от ваших плеч.

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

В примере: вы можете иметь один обработчик актер изменения его состояние на основе входящих команд, и куча различных доступных только для чтения актеров, каждый со своим собственным состоянием оптимизированы для их (например, ProductActor.) (Например, ProductHistoryActor, ProductListActor). роль. Актеры, готовые к чтению, могут подписаться на поток событий, чтобы прослушивать входящие сообщения об изменениях состояния актера обработчика и соответственно обновлять их собственные состояния, в то время как обработчик актера после обработки команды публикует сообщение об изменении состояния с использованием потока событий актерской системы.

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

var psDTO = actor.Ask<ProductStateDTO>(message).Result; 
Sender.Tell(ps); 

вы могли бы просто написать:

actor.Forward(message); 

и пусть actor отправить ответ непосредственно отправителю (вы запрашиваете актер не должен участвовать с отправкой ответа).

Объявление. 2: Это зависит от вашего дела, но помните - вы никогда не должны передавать изменяемые объекты в виде сообщений, особенно когда вы используете их после отправки.

Объявление. 3: Я думаю, что в вашем примере различие между ProductWorkerActor и ProductStateWorker является искусственным. Из того, что вы показываете, они должны быть единым объектом IMO.

+0

Отличные ответы по пунктам 1 и 2. У меня есть вдохновение, чтобы отделить Рабочего Актера и Государственного Актера от книги Essential AKKA от Jamie Allen. В этом он предлагает разделить состояние и поведение. –

+0

«actor.Forward» не работает, потому что актер - это ActorSelection. У ActorSelection нет форвардного расширения. Я не уверен, как я могу получить базового актера из ActorSelection, чтобы я мог сделать Forward. –

+0

Вперед - это в основном эквивалент 'Tell (message, Sender)'. Также будьте осторожны при работе с выборами актеров - они не должны использоваться, если они действительно не нужны. На этом есть несколько [лекций] (https://petabridge.com/blog/when-should-I-use-actor-selection/). – Horusiath

Смежные вопросы