2

我开始了一个新项目，并爱上了服务总线的概念，以在后端连接您的服务。由于到目前为止我主要从事 Web 开发，因此我只是通过 ESB 将 Web 层连接到服务。

现在我开始使用需要服务器/客户端连接的桌面应用程序，而 ESB 似乎是一个好主意，因为它默认强制使用异步模型，并且还允许在分配负载方面具有一定的灵活性。在许多情况下，Pub/Sub 也很有意义..

您在互联网上阅读了很多关于 ESB 的内容，Ayende 还制作了他的 Alexandria 应用程序，该应用程序在请求/回复场景中使用了 ESB。然后其他人说通过 ESB 进行请求/响应是一件坏事..

对于支持服务器/客户端通信的 ESB，我可能会遇到哪些大问题？

4

2 回答 2

1

这对我来说是一个非常有趣的问题，因为我从相反的角度提出了同样的问题——从 WinForms 到 Web（尽管是在 Yahoo 组，而不是 SO）。

WinForms 上的异步请求/响应对我来说开箱即用。UI 只是触发查询命令并忘记它。如果响应（带有查询结果）恰好进来，并且想要它的视图仍然可用，则将数据填充到视图中。

我试图形成一个观点，为什么使用 ESB 进行查询是“不好的”，而我能想到的最好的方法是异步模型不容易满足为 a 构建页面的要求网络应用程序。与其他更直接的查询方法相比，还有一些性能损失。

我不喜欢“只是因为”的答案，所以我很感兴趣地期待对您的问题的其他回答。

于 2011-02-08T10:00:41.547 回答
1

Take a look at Udi Dahan's post on CQRS(Command/Query Segregation). This will point you to the decision points you need to make. The main challenge with a client apps is creating a message pump in the background and marshalling that data back to the UI thread. For the web, segregating queries into a more denormalized store has worked well for us, but this methodology will cause you to think a bit differently about how you build your UI. It does greatly simplify the model as you don't need to map objects 47 times to get data, which I've always struggled with justifying. Obviously the downside is more moving parts, but we found it to be worthwhile.

于 2011-02-08T14:03:08.547 回答