2

我有一个简单的现有 ASP.NET MVC Web 解决方案。基于服务器的东西将信息写入数据库。我现在要将此系统与许多其他第 3 方系统集成/同步。我想将集成处理与现有的核心处理分开，尽可能保持现有系统不变。

我的计划如下：

  1. 每当核心系统服务器上发生数据库写入时，我都会将消息写入 MSMQ 队列。
  2. 一个完全独立的基于服务器的 Windows 服务将轮询 MSMQ，查看消息并将消息写入一个或多个“出站”同步 MSMQ 队列。
  3. 其他 Windows 服务将监视“出站”同步队列，并在必要时与第 3 方系统对话，管理出站同步。

我有几个问题：我应该有一个单一的 Windows 服务来完成这一切，还是应该有几个服务，一个中央“路由”一个，一个用于每个第 3 方系统？我应该为此使用 WCF。考虑到写入初始队列的“触发器”已经在基于服务器的进程上“发生”，这对我有什么好处吗？

非常感谢。

4

2 回答 2

2

首先，一个单独的 Windows 服务总是比任何将它与您的 asp.net 运行时集成的尝试更安全。

其次，不要自己写任何东西。采用

http://code.google.com/p/masstransit/

它很简单，可以满足您的一切需求。从他们的 nuget 包中引用库，阅读一些教程，你会喜欢它。

于 2013-04-29T16:46:45.937 回答
2

要回答您的问题：

我应该有一个单一的 Windows 服务来做这一切吗

当然不。如果你想扩展路由服务，或者重新定位它怎么办？

我应该使用 WCF

如果您对 msmq 有心，那么 WCF 为您提供的唯一优势是它提供了一种方便且经过验证的方式来设计和托管您的服务端点，并且是在 System.Messaging 中胡闹的替代方案。我会说在这个阶段这并不重要。

那能给我带来什么吗

不确定您的意思，但正如 Wiktor 在他的帖子中所说，您可以选择不使用 vanilla .Net 或 WCF，并选择服务总线类型的框架，例如 masstransit 或 nservicebus。

这里的好处是它使您远离消息传递子系统，因此您理论上可以在未来从 msmq 转移到 rabbitmq 或 azure 队列。

于 2013-05-01T12:43:42.057 回答