设计决策- WCF服务或共享类库(DLL)

Question

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

欲了解更多信息：

队列存储在SQL数据库中。

我们希望有大约3-7个不同的应用程序/客户端使用这个消息队列系统。

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

·我们预计不会有大量的消息每天排队(每天大约有1000至10000条消息排队(粗略估计数))

·“任务关键”--如果无法获得此服务，多个客户/应用程序无法完成其工作。

·所有东西都在公司网络内运作-不需要上网。

不过，我对每项决定的利弊作了一些说明：

WCF服务

Pros:

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

·可伸缩性的空间--但很可能不会成为一个问题。

Cons:

更难诊断/调试

·部署时需要付出更多努力

如果服务中断，队列系统不可用(除非我们集群/农场)

共享类库(DLL)

Pros:

·易于调试

·更容易的发展努力

只需确保数据库可用--不依赖其他服务/机器。

Cons:

当我们更新DLL时，可能会忘记更新依赖于DLL的所有应用程序。

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

耽误您时间，实在对不起,

禤浩焯

Answer 1

你可以两者兼得：

• 实现了一个类库，它封装了您希望公开的所有功能。希望控制级别的使用者可以引用库directly.
• Develop，这是一个仅作为类库的远程外观的WCF服务。它只会公开类库并将类库转换为DTO/消息，并且它本身不包含任何逻辑。

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

也就是说，我必须选择一个或另一个，我将尝试在你的想法中添加我自己的想法(我认为这是最有说服力的)。

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

即便如此，选择最好的模型并不仅仅是计算每个正反节中的子弹数，因为每个子弹都有不同的权重。

在不了解您的确切情况和需求的情况下，我仍然认为与直接使用类库有关的部署/版本控制问题是反对该策略的非常有力的论据。

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

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

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

考虑到你提供的信息，我认为这里没有明确的赢家。尽管WCF增加了复杂性，但我还是稍微倾向于WCF，因为我认为它提供的灵活性为您提供了更好的选项来响应不可预见的更改。