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

我目前正在设计一个消息队列系统，该系统将由各种应用程序使用，我很难决定是使用WCF提供服务，还是使用共享类库（DLL）并将DLL与客户端一起部署

有关其他信息：

•队列存储在SQL数据库中

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

•客户端/应用程序可能在一台机器上运行，也可能不在一台机器上运行

•我们预计每天不会有大量消息排队（大约每天1000-10000条（顺便说一句，总估计数））

•有些“关键任务”-如果此服务不可用，则多个客户端/应用程序无法完成其工作

•一切都在公司网络内运行–无需访问互联网

我对每个决定的利弊作了一些思考：

WCF服务

优点：

•可以更新队列系统中的逻辑，而无需更新客户端

•可扩展性空间–但很可能不会成为问题

缺点：

•更难诊断/调试

•部署时需要更多的努力

•如果服务关闭，队列系统不可用（除非我们群集/场）

共享类库（DLL）

优点：

•易于调试

•更容易的发展努力

•只需确保DB可用–不依赖其他服务/机器

缺点：

•更新DLL时的部署难题–我们可能会忘记更新依赖DLL的所有应用程序

如果有人能为解决方案提供更多的论据，那将非常有帮助！如果你认为什么是最好的方向，请告诉我！我将感谢任何有助于我做出决定的意见

谢谢你抽出时间

阿德里安

你可以同时做两件事：

• 实现一个类库，它封装了您希望公开的所有功能。希望达到该控制级别的用户可以直接引用库
• 开发一个WCF服务，它只充当类库的远程门面。它将只公开类库并将其转换为DTO/消息，本身不包含任何逻辑

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

---

也就是说，我认为你必须选择其中一个，我将尝试在你的想法中加入我自己的想法（我认为这是最合理的）

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

即便如此，选择最佳模型不仅仅是计算每个赞成/反对部分中的子弹数量，因为每个子弹都有不同的重量

不知道您的具体情况和要求，我仍然会考虑部署/版本化问题，它涉及直接使用类库来反对该策略。

只要合同保持稳定，web服务接口将允许您独立地改变服务和每个客户机。这也可以通过类库实现，但更困难

可互操作的web服务界面还使您能够更好地增长和响应新的业务机会，因为客户端不受.NET应用程序的限制。您现在可能只有.NET应用程序，但您确定它将永远保持这种状态吗

另一方面，如果您决定使用类库，请确保每个客户机都使用抽象基类，因为这将为您提供在不破坏现有客户机的情况下更改实现的最灵活选项

---

根据你提供的信息，我认为这里没有明确的赢家。尽管增加了复杂性，我还是略微倾向于WCF，因为我认为它提供的灵活性为您更好地响应未知的变化提供了更好的选择。这是我开发WCF服务的典型方式，但是在我们的例子中，我们希望所有客户端都使用DLL或WCF（我们认为这两者都是维护方面的难题）。我们想知道是否应该引用共享DLL或共享web服务。如果将来我们意识到我们可能需要WCF，那么共享DLL将与“远程facade”连接，所有客户端都将更新为使用WCF服务。感谢您的澄清。我已经扩展了我的回答，以更好地解决你问题的这一方面（尽管我没有明确的答案）。@Mark：写得很好，我同意你的“我稍微倾向于WCF”也：-）应该很容易将服务分散到多个web服务器上以提供故障转移保护。您忘记的WCF的一个缺点是它确实增加了一些处理开销，因为它必须序列化和反序列化消息。-是的，但同时，它还提供了一个更解耦的系统，从长远来看为您提供了更大的灵活性run@marc_s：是的，我同意，这正是我想说的，尽管您也可以在没有WCF的情况下制造耦合度非常低的系统：）