用于客户端/服务器通信的 NServicebus？
我正在开始一个新项目，并爱上了在后端连接服务的服务总线的概念。由于到目前为止我主要从事 Web 开发，因此我只是通过 ESB 将 Web 层连接到服务。
现在我开始开发一个需要服务器/客户端连接的桌面应用程序，ESB 似乎是一个好主意，因为它默认强制使用异步模型，并且还允许在分配负载方面具有一定的灵活性。此外，Pub/Sub 在很多情况下都非常有意义。
您在互联网上阅读了很多关于 ESB 的文章，Ayende 还制作了他的 Alexandria 应用程序，该应用程序在请求/回复场景中使用了 ESB。然后其他人说通过 ESB 进行请求/响应是一件坏事。
使用支持服务器/客户端通信的 ESB 可能会遇到哪些大问题？
I am starting out on a new project and have fallen in love with the concept of a Service Bus to connect your services on the backend. Since I was mostly doing Web development so far I was simply connecting the Web tier to the services over the ESB.
Now I am starting out on a Desktop Application that requires Server/Client connectivity, and an ESB seems like a good idea since it forces an Async Model by default and also allows some flexibility in distributing load. Also Pub/Sub makes a lot of sense in many cases..
You read a lot on the internet on ESB, Ayende also did his Alexandria App that used an ESB in a Request/Reply scenario. Then others say doing Request/Response over an ESB is a bad thing..
What are the big problems I am likely to see with a ESB backing my Server/Client communication?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
查看 Udi Dahan 关于 CQRS 的帖子（命令/查询隔离）。这将为您指明需要做出的决策点。客户端应用程序的主要挑战是在后台创建消息泵并将数据编组回 UI 线程。对于网络来说，将查询分离到更加非规范化的存储中对我们来说效果很好，但这种方法会让您对如何构建 UI 产生一些不同的思考。它确实极大地简化了模型，因为您不需要映射对象 47 次来获取数据，而我一直在努力证明这一点。显然，缺点是移动部件较多，但我们发现这是值得的。
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.
这对我来说是一个非常有趣的问题，因为我从相反的角度提出了同样的问题 - 从 WinForms 到 Web（尽管在雅虎组，不是这样）。
WinForms 上的异步请求/响应对我来说非常有用。用户界面只是触发查询命令并忘记它。如果恰好收到响应（带有查询结果），并且需要它的视图仍然可用，则数据将填充到视图中。
我试图形成一个观点，解释为什么使用 ESB 进行查询是“不好的”，我能想到的最好的办法是，异步模型不容易满足构建页面的要求。网络应用程序。与其他更直接的查询方法相比，性能也有一些损失。
我不喜欢“仅仅因为”的答案，所以我饶有兴趣地期待着对你的问题的其他答复。
This is a really interesting question for me because I have asked the same question from the opposite viewpoint - coming from WinForms to Web (though on the Yahoo group, not SO).
Async request/response on WinForms worked great for me out of the box. The UI just fires off the query command and forgets about it. If a response (with query results) happens to come in, and the view that wants it is still available, the data is populated to the view.
I am trying to form a view of why it is "bad" to use the ESB for queries, and the best I can come up with is that the async model doesn't easily fit in with the requirements of building up a page for a web app. Also there's a bit of a performance penalty over other more direct query methods.
I don't like the answer "just because", so I look forward with interest to the other responses to your question.