在商业应用中，想法是动态和日常指数增长。 没有这样的服务合同适合所有要求，也没有很多合同。 让我们说我们最终签订了10万份合同，最终达到10万个终点。
有没有人遇到这些问题，他们受到WCF的限制？ 或WCF不是用于真正的业务应用程序，而是与业务应用程序的集成，并暴露了一小部分数据交换？
有人可以表达一些想法吗？
此致
谢谢Chris，
我发现很难相信，100K表是虚构的，但近2000张表是正常的。
假设一个具有100K表的应用程序，对于每个服务契约，它需要接收或返回一个可序列化的对象，在这种情况下它是一个表实体。 这意味着100K表最终将获得100K服务合同，并且每个表都有一些基本实现，例如findby主键，返回某种数组或列表的查询方法以及更新/插入的写入方法。
在表格之上，我们会有很多业务逻辑方法。例如，SalesOrderTable还有一些方法，例如从qoute创建，可用于承诺，总额，折扣，税收......等等。
您如何获得可以向客户端提供此类信息的服务合同，而没有多个合同接口/端点？
答案 0 :(得分：1)
你的问题有点抽象，所以可能更适合http://programmers.stackexchange.com，但我认为在真正得到答案之前还有一些问题需要澄清。
目前还不清楚这是什么意思'WCF不适用于真正的业务应用程序，而是与业务应用程序的集成'。如果与您添加的一些注释结合使用，则有点像您建议您在服务+数据库表或类之间进行1：1映射。目前还不清楚业务逻辑方法（例如“从引用创建”是否位于服务接口后面（因此业务逻辑位于服务中），或者位于服务前面（即业务逻辑位于客户端）。
你似乎也在担心目前似乎是一个虚假的要求（100k表/服务），因为目前你似乎正在处理2k表......目前还不清楚你的一些想法在哪里来自，例如每个合同的12个推荐操作（示例中的ITradeService已经指示有19个操作）。
WCF能否扩展到100k服务？是的，但是如果您尝试使用100k类或100k表建模系统，那么您将遇到类似的问题。您将要以适当的方式对数据/逻辑进行分区，以便它们可以处理开销/要求，从而使它们相对直观易用。这可能意味着您希望跨多个服务器分发服务。
然而，正如我在评论中所说，这对你来说似乎是一个非常奇怪的情况。如果你需要建模100k服务，那么你要么试图通过服务暴露太多，或者你有一个特别大的域，你想要建模。
通常，我希望服务处于比数据库模型更高的抽象级别。例如，让我们采用典型的客户模型......数据库可能包含以下表格：
您可以将每个表作为CRUD操作从服务公开，但这似乎是一个坏主意。然后，“注册客户”的逻辑可以位于客户端。他们必须以正确的顺序创建所有表条目以维护数据库完整性。另一种方法是拥有一个包含操作'RegisterCustomer'的'Customer'服务，该服务接收DataContract'NewCustomerData'，其中包括基本的客户详细信息，地址详细信息，电话号码详细信息等...只有一个需要操作而不是很多才能实现相同的结果，并且客户端交互更容易，更不容易出错。
不是一个完整的答案，但也许是一些开始......你可能还想看看Principles of Service Design: Service Patterns and Anti-Patterns。虽然它有点陈旧，但它确实涵盖了一些有用的主题。我建议在这一点上，您可能需要更多地考虑一下您正在尝试实现的目标，以及在看到更具体的问题之前您是如何看待模型的。（/ p>