Prism 事件聚合器持久事件
Prism event aggregator Persistent Events
我在我的服务器上实现了 Prism 事件聚合器，其中一个服务发布一个事件，另一个服务监听它。
我的订阅码：
my_aggregator.GetEvent<MyEvent>().Subscribe(Handler,true);
而我将活动发布为：
my_aggregator.GetEvent<MyEvent>().Publish(Payload);
The thing is that if the subscriber is alive then, everything works fine. But, lets say an event is published and the subscriber (is a service) somehow shuts down. Is there a way by which when the subscriber comes alive again it can respond to the event that was fired.
我查看了 netmsmq 绑定以及它如何在服务之间提供队列，因此即使服务器关闭也可以避免数据丢失。
我必须将它与我当前的机制挂钩吗？
还是有其他方法可以实现？？
是否有处理此问题的标准机制？
编辑： 如果您能提供一个 link/code 片段来描述实现此目标的途径，那将非常有帮助。
PRISM 事件聚合器仅保证在发布者引发事件时通知订阅者（同步或异步）。它不能保证订阅者正确处理 "event"。在您的例子中，订阅者的 Handler 被调用。这就是事件聚合器 can/should 所做的全部。为确保您的 Handler 正常工作（取决于服务是否存在）并且不会错过任何 Payload，您绝对需要类似 queue 的机制。
您正在寻找 "store and forward" 机制。几年前，我使用this article by Ade Miller中描述的方法完成了同样的事情。然而，我已经有几年没有对 Prism 做太多了，这篇文章大约是 2008 年的，所以虽然描述的 方法 可能仍然适用，但实际实现可能与更新版本的 Prism...
我在 codeplex 论坛上发布了这个问题，并从 Bryan Noyes 那里得到了 answer。它是：
I'm afraid you are cleanly outside what Prism pub-sub events were designed for. They were designed for loosely coupled components that are all in memory at the same time on the client side but you don't want to introduce coupling between those client components for them to communicate. For the kind of scenario you are talking about server side queues of some sort are the right answer, whether they are MSMQ-based, RabbitMQ, or Service Bus queues for Service Bus for Windows Server (or many other options along those lines depending on whether you want the queue to be on premise or in the cloud).
所以简而言之，对于服务器端事件，棱镜 pubsubevents 不是一个好主意。
我在我的服务器上实现了 Prism 事件聚合器，其中一个服务发布一个事件，另一个服务监听它。 我的订阅码：
my_aggregator.GetEvent<MyEvent>().Subscribe(Handler,true);
而我将活动发布为：
my_aggregator.GetEvent<MyEvent>().Publish(Payload);
The thing is that if the subscriber is alive then, everything works fine. But, lets say an event is published and the subscriber (is a service) somehow shuts down. Is there a way by which when the subscriber comes alive again it can respond to the event that was fired.
我查看了 netmsmq 绑定以及它如何在服务之间提供队列，因此即使服务器关闭也可以避免数据丢失。
我必须将它与我当前的机制挂钩吗？ 还是有其他方法可以实现？？ 是否有处理此问题的标准机制？
编辑： 如果您能提供一个 link/code 片段来描述实现此目标的途径，那将非常有帮助。
PRISM 事件聚合器仅保证在发布者引发事件时通知订阅者（同步或异步）。它不能保证订阅者正确处理 "event"。在您的例子中，订阅者的 Handler 被调用。这就是事件聚合器 can/should 所做的全部。为确保您的 Handler 正常工作（取决于服务是否存在）并且不会错过任何 Payload，您绝对需要类似 queue 的机制。
您正在寻找 "store and forward" 机制。几年前，我使用this article by Ade Miller中描述的方法完成了同样的事情。然而，我已经有几年没有对 Prism 做太多了，这篇文章大约是 2008 年的，所以虽然描述的 方法 可能仍然适用，但实际实现可能与更新版本的 Prism...
我在 codeplex 论坛上发布了这个问题，并从 Bryan Noyes 那里得到了 answer。它是：
I'm afraid you are cleanly outside what Prism pub-sub events were designed for. They were designed for loosely coupled components that are all in memory at the same time on the client side but you don't want to introduce coupling between those client components for them to communicate. For the kind of scenario you are talking about server side queues of some sort are the right answer, whether they are MSMQ-based, RabbitMQ, or Service Bus queues for Service Bus for Windows Server (or many other options along those lines depending on whether you want the queue to be on premise or in the cloud).
所以简而言之，对于服务器端事件，棱镜 pubsubevents 不是一个好主意。