设计决策 - WCF服务或共享类库（DLL）

Question

我目前设计将各种应用程序中使用消息队列系统，和我有困难的时候试图决定是否使用WCF提供的服务或使用共享类库（DLL）并与客户端部署DLL。

有关其他信息：

•队列存储在SQL数据库中。

•我们预计使用该消息队列系统有大约3-7不同的应用程序/客户端。

•客户端/应用程序可能会或可能不会在一台计算机上运行。

•我们不希望每天都在排队消息的重负载（约1000-10000每天（总值估计BTW））

•有点“关键任务” - 几个客户端/应用程序不能做它的工作，如果这项服务不可用。

•一切都在企业网络内运行 - 不需要访问互联网。

我已经给了一些，虽然对利弊的每一个决策：

WCF服务

优点：

•可以更新队列系统的逻辑，而不必更新客户端

房•可扩展性 - 但最有可能不会成为一个问题。

缺点：

•更难以部署

•排队系统无法使用该服务是否下降（除非我们集群​​/场）

时诊断/调试

•需要更多的努力

共享的类库（DLL）

优点：

•易于调试

•易于开发力度

•只需要确保DB可用 - 另一个服务/机上没有依赖。

缺点：

•部署头痛时，我们会不断更新的DLL - 我们可能会忘记更新所有依赖于该DLL的应用程序。

如果任何人都可以提供更多的解决方案的参数 - 这将是有益的！如果你对你认为最好的方向有看法，请告诉你！我会很感激任何有助于我做出决定的意见。

感谢您的时间，

阿德里安

Answer 1

你既可以做：

• 实现一个类库，封装了所有你想公开的功能。希望这种控制水平的消费者可以直接参考图书馆。
• 开发仅充当类库的远程门面的WCF服务。它只会将类库公开并翻译成DTO /消息，本身不包含任何逻辑。

换句话说，类库是你的域模型，服务只是该模型前面的一个瘦门面。这就是任何情况下都应该开发任何WCF服务的方式。

---

这就是说，我给你必须选择一个或其他的，我会尽量自己想添加到你（这是我觉得最reaonable）。

您忘记了WCF的一个缺点是它增加了一些处理开销，因为它必须序列化和反序列化消息。

即便如此，选择最佳模型不仅要计算每个pro/con部分中的子弹数量，因为每个子弹的权重不同。

如果不知道确切的情况和要求，我仍然认为与直接使用类库有关的部署/版本问题是违反该策略的非常有力的论据。

只要合同保持稳定，Web服务接口将允许您改变服务和每个客户的相互独立。这也可以通过班级图书馆来实现，但更困难。

由于客户端不受.NET应用程序的限制，可互操作的Web服务接口还使您能够更好地发展和响应新的商业机会。你今天可能只有.NET应用程序，但你确定它会永远保持这种方式吗？如果另一方面，如果您决定走上类库路由，请确保每个客户端都使用抽象基类，因为这将为您提供在不破坏现有客户端的情况下更改实现的最灵活选项。

鉴于您提供的信息，我认为这里没有明确的赢家。尽管增加了复杂性，但我依然略微倾向于WCF，因为我认为它提供的灵活性为您提供了更好的选项来响应未发生的变化。