WCF 服务合同设计

Question

在业务应用程序中，创意是动态的，每天呈指数级增长。 并且没有这样的服务合同符合所有要求，也没有许多合同。 假设我们最终获得了 100 000 个合同，它们最终获得了 100 000 个端点。

有没有人遇到过WCF限制的这类问题？ 还是 WCF 不是针对真正的业务应用程序，而是与业务应用程序的集成并暴露了一小部分数据交换？

有人可以提出一些想法吗？

问候

谢谢克里斯，

我也觉得难以置信，100K 表是虚构的，但近 2000 个表是正常的。

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

在一个表之上，我们会有很多业务逻辑方法。例如，SalesOrderTable 也会有诸如 create from qoute 等方法，可用于 promise、total、discount、tax...等

如果没有很多合同接口/端点，您将如何拥有可以向客户端提供此类信息的服务合同？

Answer 1

您的问题有点抽象，所以可能更适合http://programmers.stackexchange.com，但我认为仍有一些问题需要弄清楚才能真正回答。

不清楚您所说的“WCF 不是用于真正的业务应用程序，而是用于与业务应用程序的集成”。当与您添加的一些 cmets 结合使用时，它看起来有点像您建议您在服务 + 数据库表或类之间进行 1:1 映射。目前尚不清楚业务逻辑方法，例如“从报价创建”是位于服务接口之后（因此业务逻辑在服务中），还是位于服务前面（即业务逻辑在客户端中）。

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

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

但是，正如我在 cmets 中所说，这对您来说似乎是一个非常奇怪的情况。如果您需要对 100k 服务建模，那么您要么试图通过服务公开太多，或者您有一个非常大的域要尝试建模。

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

• 客户 – 核心客户详细信息，由 id 键入
• 地址 - 代表邮政地址
• 客户地址 - 在给定的时间段内将客户映射到地址
• 电话号码 - 代表电话号码
• 客户电话号码 - 在给定的时间段内将客户映射到电话号码，包括类型（手机、家庭等）
• 等等……

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

不是一个完整的答案，但也许可以开始......您可能还想看看Principles of Service Design: Service Patterns and Anti-Patterns。虽然它有点旧，但它确实涵盖了一些有用的主题。我建议，在这一点上，您可能需要更多地考虑一下您想要实现的目标以及您如何看待您的模型，然后再提出更具体的问题。