0

我的系统使用带有单独处理程序的命令模式。我的命令在当前处理所有正在处理的命令的 CommandService 上执行。

我有某些命令至少会执行其中一项缓慢的操作：

  1. 发送电子邮件
  2. 生成 PDF
  3. 发送传真
  4. 与第 3 方 Web 服务交互

我希望所有这些命令都在进程外处理，以便 UI 更加灵活。

我应该只为这些命令使用消息总线，还是应该调用进程内命令处理程序BeginInvoke()？

编辑 - 附加信息

该系统的用户数量很少（在忙碌的一天可能有 100 个并发用户），因此队列可能永远不会变得很长。这里的主要内容是减少发送带有附件 PDF（相关命令）的电子邮件时 UI 被阻止的时间。员工必须在一天内多次执行该命令。

考虑到整个情况，我想我现在要考虑BeginInvoke()以下几个原因：

  1. 必须触摸所有 UI 交互以确保它们的行为就像命令成功一样。“您需要发送此文档”的提醒在 UI 中的多个位置，并且在发送报告后会刷新整页。
  2. 这是我客户繁忙季节的中间时间（他们在夏季完成了超过 50% 的年度业务），所以此时引入一个我不熟悉的全新基础架构对我来说似乎并不明智管理.

但是知道我现在所知道的，在一个新系统上，我会从一开始就使用服务总线来处理任何慢速命令（实际上每个系统都需要发送电子邮件）并设计 UI，以便更容易地从同步切换命令到异步处理。在实现中，这基本上意味着每个 POST 都是 AJAX 并在 UI 中执行一个动作，就好像它成功了一样。（例如，查看 Facebook 如何处理评论。）

4

2 回答 2

2

可能更多的是可靠性问题，将您推向消息总线。您会看到，如果您的原始事务（执行 BeginInvoke 的事务）成功，然后在您调用的中途服务器崩溃，您的系统将没有内存，它仍然需要发送电子邮件或生成 PDF .

消息总线将能够将第二个事务回滚到队列中，以便当服务器再次启动时，它会再次发送电子邮件。

于 2012-07-29T07:15:13.997 回答
2

两种解决方案都有其优点和缺点。

  • BeginInvoke 是非常简单的解决方案，其语义与直接通过命令调用处理程序相同。但是这个解决方案取决于线程基础设施：最大线程数、由于并发访问 IO 资源而导致的冻结线程等。
  • MessageBus 是非常灵活且功能强大的解决方案，您可以在其中控制命令处理过程的各个方面。但是它为您的应用程序引入了另一个抽象层，如果更简单意味着更好，这将是一个过度工程

我建议估计您的系统负载要求、这些后台任务的数量、增长因素等，并据此做出决定。

但在我个人看来，引入适用于 80% 案例的总线解决方案。您可以引入一个简单的总线实现，如果需要，可以在下一次迭代中进行扩展。

于 2012-07-27T23:14:21.747 回答