wcf决策:一个服务多个合同或多个服务

本文关键字：服务 合同 一个 wcf 决策 | 更新日期: 2023-09-27 18:20:51

我正在使用.NET 4为客户创建一个小型客户端-服务器应用程序。我应该创建一个实现多个合约（IInvoice、IPurchase、ISalesOrder等）的大型服务，还是应该创建多个服务，每个服务在多个端口上运行一个合约？我的问题特别感兴趣的是这两种选择的利弊。此外，回答这个问题的常见方式是什么？

我真正的困境是，我没有做出这个决定的经验，而且我在wcf方面的经验也很少，我需要帮助理解这样一个决定的技术含义。

wcf决策:一个服务多个合同或多个服务

不要创建一个实现n个服务合同的大型服务。这些类型的服务很容易创建，但最终会成为一个令人头疼的维护问题，并且无法很好地扩展。此外，如果有一个开发小组在争夺签入/签出，您将遇到各种代码合并冲突。

也不要创建太多服务。避免让服务过于细粒度的陷阱。尝试基于某个功能创建服务。这些服务公开的方法也不应该是细粒度的。你最好少用一些能做更多事情的方法。通过创建GetUser（userObject用户），避免创建类似的函数，如GetUserByID（int ID）、GetUserByName（string Name）。您将拥有更少的代码、更容易的维护和更好的可发现性。

最后，不管你做什么，你可能只需要一个端口

更新12/2018有趣的是，自从我写这篇文章以来，事情发生了怎样的变化。现在有了微服务模式，我正在创建许多具有聊天API的服务：）

您通常会为每个主要实体创建不同的服务，如IInvoice、IPurchase、ISalesOrder。

另一个选项是将查询与命令分离。您可以为每个主要实体提供一个命令服务，并实现业务操作，只接受执行操作所需的数据（避免类似CRUD的操作）；以及一个查询服务，该查询服务以客户端所需的格式返回数据。这意味着命令部分使用底层的域模型/业务层；而查询服务直接对数据库进行操作（绕过查询不需要的业务）。这大大简化了查询，使查询更加灵活（只返回客户端需要的内容）。

在实时应用程序中，每个实体都有一个服务合同，如发票、采购和销售订单。将有单独的服务合同

然而，对于每个服务契约，都会有像Invoice这样的异构客户端。后台将使用netNamedPipeBinding或netTcpBinding通过windows应用程序调用Invoice，同时客户端应用程序需要使用basicHttpBinding或wsHttpBindings调用服务。基本上，您需要为每个服务创建多个端点。

您似乎在DataContract和ServiceContract之间混合。您可以有一个ServiceContract和多个DataContract，这将非常适合您的需求。

事实是，拆分WCF服务或任何服务都是一种平衡行为。原则是，您希望在考虑性能的同时，对复杂性保持向下的压力。

创建的服务越多，需要编写的配置就越多。此外，您将增加需要在客户端创建和维护的代理类的数量。

在一个服务上放置太多ServiceContract会增加生成和使用代理所需的时间。但是，如果你在一份合同中只完成了一到两次操作，你将增加系统的复杂性，而几乎没有什么收获。这不是一个科学的处方，但一个好的经验法则可以说是每个服务合同大约10-20个操作合同。

类耦合当然是一个考虑因素，但你真的在处理单独的问题吗？这取决于您的系统所做的工作，但大多数系统只处理少数几个关注的领域，所以无论如何，将事情拆分实际上可能不会减少那么多类耦合。

另一件需要记住的事情是，始终使方法尽可能通用，这一点非常重要。WCF交易DataContracts是有原因的。DataContracts意味着，只要已知DataContracts，就可以向服务器发送任何对象，也可以从服务器中发送任何对象。

因此，例如，您可能有3个操作合同：

[OperationContract]
Person GetPerson(string id);
[OperationContract]
Dog GetDog(string id);
[OperationContract]
Cat GetCat(string id);

但是，只要这些都是已知的类型，你就可以将它们合并到一个操作中，比如：

[OperationContract]
IDatabaseRecord GetDatabaseRecord(string recordTypeName, string id);

归根结底，这是设计服务合同时需要考虑的最重要的事情。如果您使用类似DataContract序列化的序列化方法，则这适用于REST。

最后，每隔几个月检查一次ServiceContracts，并删除客户端未使用的操作。这又是一个大的！

您应该根据预期的负载、所需的可扩展性和未来的前景做出决定。正如您所写的"客户的小型客户端-服务器应用程序"，它并没有给出手头开发的预期用途的清晰概念。Big先生的回答也必须加以考虑。

非常欢迎您提出进一步的问题，并提供有关手头情况的具体数据或细节。谢谢

相关文章：