Events 在事件驱动体系结构中为用户提供即时响应

我已经读了很多关于事件驱动架构的书，它对我来说很有意义，但是给用户即时反馈的问题让我困惑

假设有一个包含所有员工列表的服务（“EmployeeService”）。创建员工的业务逻辑位于此服务中

来自其他系统的UI使用此服务。要求是（无论您喜欢与否）它有一个员工网格和一个“添加员工按钮”，该按钮将显示一个表单，当您提交表单时，它会将您返回到包含新员工的网格。网格显示由服务计算的派生字段（这一点需要注意！）

传统上，在提交时，我会显示一个加载屏幕，同步发送一个WCF请求来注册该员工，并在注册完成后转发到网格（该网格现在肯定会有新员工）

有了EDA，在提交时，我会“发射并忘记”一个注册用户的命令——但接下来呢？我可以转发到网格，但新员工可能还不在网格中？假设一切正常，我可以手动添加到网格中，但是如何显示服务计算的派生数据？或者，如果尚未创建“新员工待定图形”，我可以在网格上显示该图形，然后每隔几秒钟检查一次页面，直到创建完毕

---

这是一种常见的情况，那么对此的常见解决方案是什么？

您可以在发送命令时注册回调并阻止，直到命令完成

---

如果您下载了NServiceBus包，请参考AsyncPagesMvc3示例解决方案。它有一个例子，正好说明你在寻找什么

如果您的

EmployeeService

是SOA服务，则添加员工按钮也属于EmployeeService。用户界面是多个服务的简单组合。您可以在处理员工创建和计算（如果计算不复杂）的客户端上本地部署部分

EmployeeService

例如：

public class AddEmployeeView
{
   public IBus Bus { get; set; }    

   public void AddNewClicked() {
        // async calculate
        // store directly in the employee service database
        // or dispatch command internally
        // refresh employee list as the service is the only owner of that data
        Bus.Publish<NewEmployeeAdded>(m => { });
   }
}

公共类AddEmployeeView
{
公共IBus总线{get；set；}
public void AddNewClicked（）{
//异步计算
//直接存储在员工服务数据库中
//或内部调度命令
//刷新员工列表，因为服务是该数据的唯一所有者
发布（m=>{}）；
}
}

---

因此，上面的

AddEmployeeView

属于

EmployeeService

。只有

EmployeeService

知道如何计算和存储新员工（甚至在自己的数据库中），并且是

NewEmployeeAdded

事件的唯一逻辑发布者。这就省去了你的复杂性。

计算这么复杂吗？计算数据通常需要多长时间？@DanielMarbach它可能几乎是即时的，但你无法保证它。如果你被固定在网格上，那么应用EDA原理可能就不值得了。在这种情况下，RPC方法应该是很好的。要考虑的一点是消息驱动架构中有两种不同类型的消息。事件和命令。而第一个，事件，通常更容易让你头脑清醒。在您的例子中，您将以普通RPC样式添加员工，并阻止直到添加为止。事件更多的是针对行动中不相关的参与者。我知道这一特性，但在事件驱动的体系结构中应该避免这种请求/回复风格。考虑到您现有的需求，这是迄今为止最简单的解决方案。如果您有实时更新需求，并且不想遵循这样的模式，那么EDA可能不是一个好的解决方案，您可能希望遵循RPC样式（至少在您正在操作的上下文中），使用回调通常是一种不好的气味。NSB使得回归传统RPC风格的通信非常困难。尝试坚持Pub/Sub。假设AddEmployeeView是网站的一部分，那么在发布相同事件的负载平衡器后面，如何处理该视图的多个实例？据我所知，这是不可能的和/或一个好主意。网站可以向发布NewEmployeeAdded的后端发送命令。