答案 0 :(得分：4)
在您的情况下，我建议您返回IEnummerables以进行回购的数据查询。我通常通过代表域问题的服务类聚合来自多个repo的调用，并封装我的业务逻辑。为了保持清洁，我尝试让我的repros专注于域名问题。我将我的Datacontext比作回购，并使用T4模板提取界面，使生活更容易进行模拟。但是没有什么可以阻止你使用封装你的电话的传统仓库。这样做可以让你在任何阶段切换ORM。
编辑：IQueryable不是答案！ :-) 我在这个领域也做了很多工作，并且初步得出了相同的结论，但这不是一个好的解决方案。回购的要点是将查询抽象为离散的工作块。暴露出IQueryable过于自负，并在以后提出了一些问题。你失去了扩展能力。你失去了优化查询的能力（假设我想转向高度优化的存储过程）。您失去了使用IoC来备份切换数据访问层的能力（将项目从SQL切换到Mongo）。您失去了在Repo中提供有效数据缓存的能力（这是Repo模式中的主要优势）。我建议采取CLOSE外观，为什么我们有Repo模式。它不仅仅是一个“ORM”映射层。让我真正清楚的是CQRS模式。
除此之外，允许IQueryable的特殊性使您无法重复使用查询。重复查询通常不是一个好主意，因为查询查询时会看到轻微的偏差，最终会产生2个副产品：查询变得过于宽泛和低效。查询充斥着无法维护的IF THEN语句，以迎合偏差。
IQueryable很容易，但是会让你陷入难以维护的混乱状态。
答案 1 :(得分：2)
看看这个SO answer。我认为它显示了你想要的简化模型。 IQueryable<T>确实是我们的新存储库:-)。 DataContext和ObjectContext是我们的工作单位。
更新2：
Here is a blog post 描述了您可能正在寻找的模型。
更新3
将共享数据库隐藏在服务后面是明智之举。这将解决几个问题：
结果是您的应用程序将数据发送到服务以验证它。调用服务以获取数据。查询自己的私有数据库（数据库3）并将三个数据源的数据本地连接在一起。我从未成为使用跨数据库甚至跨服务器（在您的情况下）数据库调用并让数据库将所有内容连接在一起的粉丝。交易将被提升为分布式交易，很难预测服务器将交换多少数据。
当您抽象服务背后的共享数据库时，事情变得更容易（至少从您的应用程序的角度来看）。您的应用程序调用它信任的服务，这限制了该应用程序中的代码量和测试量。你仍然想模拟对这种服务的调用，但这很容易。它还应解决验证多个数据源的问题。
验证始终是一个难点。我非常熟悉验证应用程序块，并且喜欢它的灵活性。然而，这不是一个简单的框架，但你可能会看一看你可以用它做什么。例如，我在验证应用程序块中写了几篇关于与O / RM工具和how to 'embed' a context（DataContext /工作单元中的上下文）集成的文章。
答案 2 :(得分：1)
请查看我的IRepository pattern implementation using EF 4.0。
我的解决方案具有以下功能：