WCF服务契约设计

本文关键字：契约 服务 WCF | 更新日期: 2023-09-27 18:04:32

在商业应用程序中，想法是动态的，并且每天呈指数级增长。没有一个服务契约适合所有需求，也没有很多契约适合所有需求。假设我们有10万个合约它们有10万个端点

有谁遇到过这些问题，他们是由WCF限制的吗?或者WCF不是用于真正的业务应用程序，而是用于与业务应用程序的集成，并暴露了一小部分数据交换?

谁能好心地表达一些想法?

对

谢谢克里斯,

我也发现很难相信，10万张表是虚构的，但近2000张表是正常的。

假设一个拥有100K个表的应用程序，对于每个服务契约，它需要接收或返回一个可序列化的对象，在这种情况下它是一个表实体。这意味着100K的表最终会有100K的服务契约，而且每个表都有一些基本的实现，比如findby主键，返回某种数组或列表的查询方法，以及用于更新/插入的写方法。

在表的顶部，我们将有许多业务逻辑方法。例如SalesOrderTable也会有create from quote、available to promise、total、discount、tax等方法

如果没有许多契约接口/端点，你如何拥有一个可以向客户端提供这些信息的服务契约?

WCF服务契约设计

你的问题有点抽象，所以可能更适合http://programmers.stackexchange.com，但我认为在真正回答之前还有一些问题需要澄清。

我不清楚你所说的"WCF不是用于真正的业务应用程序，而是用于业务应用程序的集成"是什么意思。当与您添加的一些注释结合在一起时，它读起来有点像您建议在服务+数据库表或类之间进行1:1的映射。目前还不清楚业务逻辑方法，如"create from quote"是位于服务接口后面(因此业务逻辑在服务中)，还是位于服务前面(即业务逻辑在客户端中)。

您似乎还在担心目前似乎是一个虚假的需求(100k表/服务)，因为目前您似乎正在处理2k表…也不清楚您的一些想法来自哪里，例如每个合约推荐的12个操作(您指出的示例中的ITradeService有19个操作)。

WCF能够扩展到100,000个服务吗?是的，但是，您将遇到类似的问题，如果您试图为具有100k个类或100k个表的系统建模，您将遇到类似的问题。您将希望以适当的方式划分数据/逻辑，以便它们能够处理开销/需求，并且使用起来相对直观。这可能意味着您希望将服务分布在许多服务器上。

然而，正如我在评论中所说的，这对你来说似乎是一个非常奇怪的情况。如果您需要对100k个服务进行建模，那么要么您试图通过服务公开太多内容，要么您有一个非常大的域要尝试建模。

一般来说，我希望服务处于比数据库模型更高的抽象级别。让我们以一个典型的客户模型为例……数据库可以由如下表组成:

  • 客户-核心客户详细信息，按id
    • 键输入
  • Address -表示邮政地址
  • 客户地址-在给定时间段内将客户映射到地址
  • 电话号码-表示电话号码
  • 客户电话号码-将客户映射到电话号码，在给定的时间段内，包括类型(移动，家庭等)
  • 等等…

您可以将每个表公开为来自服务的CRUD操作，但这似乎不是一个好主意。然后，"注册客户"的逻辑可能位于客户端。他们必须按照正确的顺序创建所有表项，以维护数据库的完整性。另一种选择是拥有包含操作"RegisterCustomer"的"Customer"服务，该服务接受DataContract"NewCustomerData"，其中包括基本的客户详细信息、地址详细信息、电话号码详细信息等……只需要一个操作，而不是许多操作，就可以获得相同的结果，并且客户端交互更容易，更不容易出错。

不是一个完整的答案，但也许可以开始…您可能还想看一下服务设计原则:服务模式和反模式。虽然它有点旧，但它确实涵盖了一些有用的话题。在这一点上，我建议您在提出更具体的问题之前，可能需要更多地考虑您想要实现的目标以及您如何看待您的模型。

相关文章：