问2+ OData订阅源之上的OData

EN

我不会在客户端库上使用反射提供程序，主要是因为客户端库LINQ提供程序并不支持服务器使用的所有构造。因此，有些查询根本无法工作(投影和扩展通常会中断)。假设您不想在数据库之间创建任何关联，您应该能够简单地将用户指向正确的服务。您仍然可以公开一些看起来像统一端点的东西，而不需要所有这些端点都具有相同的URL。

主要思想是统一$metadata (如果您的模型是静态的，您可以手动完成此操作，否则您应该能够非常容易地编写某种“合并”工具)，然后提供指向每个实体集的相应URL的服务文档。在WCF Data Services客户端中，现在可以通过实体集解析器来支持这些类型的服务：http://blogs.msdn.com/b/astoriateam/archive/2011/06/30/announcing-wcf-data-services-june-2011-ctp-for-net4-amp-sl4.aspx带有这种支持的最新http://blogs.msdn.com/b/astoriateam/archive/2010/11/29/entity-set-resolver.aspx在这里

对这个问题目前被接受的答案并不满意，对我来说，这更多的是一种反答案，即什么不应该做。我的解决方案在今天和'11年的时候一样适用

为了支持租户场景，其中每个用户/客户端数据将始终驻留在同一数据库中，并且所有数据模式都匹配，那么您所需要做的就是在实例化数据上下文时更改连接字符串。

这个概念的另一个术语是分片，微软有一些工具和API可以帮助你，这是一个足够简单的演练：Azure SQL Database Elastic database tools: Shard Elasticity，但你可以从第一个原则很容易地做到这一点。

如果交换连接字符串对您的场景有效，我们需要确定您将用于确定连接字符串的机制，有两种常见的解决方案：

1. 简单的解决方法是在每个服务请求中使用固定的主机头、路由或令牌，然后您可以硬编码用于确定连接字符串的逻辑，而无需复杂的映射逻辑。
2. 使用主/头/映射DB来存储您的配置。

这个数据库有一个单独的模式，它的主要用途是为每个请求检索正确的连接字符串。在大多数情况下，我们将其与身份验证过程相结合，在这种情况下，您将身份验证保存在此中央数据库中，而不是单个数据库中。

就OData控制器而言，即使使用WCF，您也只需要实现用于检索连接字符串的逻辑，并在实例化数据上下文时使用该逻辑。

当然，如果您的客户端数据分布在多个数据库中，这对您没有帮助，但这是一个非常常见的模式，用于搜索大型数据库，而不必为每个数据库部署新的服务场。