我们真正在寻找哪种 mvc3 / c# 技术/架构 - nservicebus、WCF 还是其他？
这就是我们需要做的。
我们有一个 Web 应用程序 (MVC3)，允许管理各种实体。比如说“学校”、“学生”和“老师”。
当这些实体中的任何一个发生更改（创建、更新或删除）时，我们需要将更改告知另一个系统。我们无法控制其他系统，但我们可以访问网络服务，让我们对其进行实时更新。
我知道我不希望我们的用户在连接到此 Web 服务并进行更新时等待，因此我们必须需要一种方法来对更新进行排队并在完全独立的过程中进行更改。
我真的很感激任何解决这个问题的架构指针。我确信现有的框架可以管理这个队列，例如，如果通信中断，我们可以重新发送数据 - 但我不知道该看哪些框架。
干杯!
Here's what we need to do.
We have a web application (MVC3) that allows various entities to be managed. Let's say "schools", "students" and "teachers".
When any of these entities changes (created, updated or deleted) we need to tell another system about the change. We're not in control of that other system, but we have access to a web service that lets us make real time updates to it.
I know I don't want our users to wait around while we connect to this web service and make the updates, so we must need a way to queue updates and make the changes as part of a totally separate process.
I'd really appreciate any architectural pointers for solving this problem. I'm sure there are existing frameworks that will manage this queue and let us, for instance, resend data if communications are interrupted - but I don't know which frameworks to look at.
Cheers!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
NServicebus 将提供您所需的排队。它提供事务支持，并在您需要重新处理失败消息的情况下返回到源队列实用程序。我在这里推荐第三个系统来处理调用 Web 服务。该消息处理程序将从队列中读取并调用 Web 服务。
客户->发布 NServiceBus 消息 ->消息处理程序-> Web 服务
该消息处理程序将为您提供所需的关注点分离。
NServicebus would provide the queueing you require. It provides transactional support, and a return to source queue utility in the case that you need to re-process a failed message. I would recommend a third system here to deal with calling the web service. This message handler would read from the queue and call the web service.
Client -> Publish NServiceBus Msg -> MessageHandler -> Web Service
This message handler will then give you the separation of concerns that you require.
需要数据更新的其他供应商/客户不依赖于您的应用程序。至少从你的解释来看不是。它们依赖于准确的数据。这意味着您的问题是数据问题，而不是应用程序问题。从这个角度来看，数据解决方案看起来很性感。
如果您使用 SQL Server，我会考虑在数据库上使用触发器并在那里启动。如果您想完全卸载数据库操作和应用程序的工作，那么 SQL Server Service Broker 就可以很好地工作。
如果您使用另一个数据库平台，您可能有或很多没有排队服务。在这些情况下，您可能需要服务总线，但我会看看是否有更简单可靠的异步方法可以首先使用。
The other vendor/client that needs data updates is not dependent on your application. At least not from your explanation. They are dependent on accurate data. This means your issue is a data issue, not an application issue. From that standpoint, a data solution looks sexy.
If you are using SQL Server, I would consider using triggers on the database and initiating there. If you want to completely offload the work from both the database operations and the application, then SQL Server Service Broker works nicely.
If you are on another database platform, you may or many not have a queueing service. In these cases, you might require a service bus, but I would see if there is a simpler reliable async method you could use first.