linq - 具有“现代”数据访问策略的存储库模式

Question

因此，当我发现将整个解决问题的方法颠倒过来时，我正在网上搜索最佳实践，以实现使用多个数据存储的存储库模式。这就是我所拥有的...

我的应用程序是一个BI工具，它从四个数据库中提取数据。由于内部限制，我目前正在使用LINQ-to-SQL进行数据访问，但是需要一种允许我更改为Entity Framework或NHibernate或下一次进行数据访问的设计。我还坚持使用IoC框架（在这种情况下为城堡温莎）在应用程序中分离层。

这样，我就使用了Repository模式来从我的业务层抽象出实际的数据访问代码。结果，我的业务对象针对某些I Repository接口进行了编码，并且IoC容器用于管理实际的实现。在这种情况下，我希望有一个具体的Linq Repository，该存储库使用LINQ-to-SQL来实现接口以完成工作。稍后，我可以用EF Repository替换它，而无需更改我的业务层。

另外，由于我针对接口进行编码，因此我可以轻松模拟存储库以进行单元测试。

因此，在开始编写应用程序代码时，我遇到的第一个问题是，是否应该为每个DataContext或每个实体（如我通常做的那样）拥有一个存储库？假设一个数据库包含具有预期关系的“客户”和“销售”。我应该拥有一个同时使用两个实体的方法的OrderOrderingRepository还是拥有一个单独的CustomerRepository和一个不同的SalesRepository？

接下来，作为BI工具，主要接口用于报告，制图等，并且通常将需要跨多个源的数据“混搭”。例如，现实是一个数据库包含客户信息，而另一个数据库则处理销售信息，而第三个数据库则包含其他财务信息，但是我的要求之一是显示跨越所有这三个数据库的汇总信息。另外，我必须在UI中支持动态过滤。显然，直接针对LINQ-to-SQL或EF DataContext对象（例如Table ）工作将使我几乎可以做任何事情。使用存储库接口抽象DAL时，将相同功能暴露给我的业务逻辑的最佳方法是什么？

本文： link text表示EF4已经扭转了这种方法，并且该存储库不过是从EF DataContext返回的IQueryable而引发的另一组问题。

但是，我想我已经够忙了...

更新（谢谢，史蒂文！）

好的，让我在桌上摆一个更具体的示例（至少对我来说），并澄清一些要点，希望可以找到一种方法，让我可以更好地解决问题。

虽然我了解Steven提出的建议，但我拥有一个开发人员团队，在实施此类事情时我必须考虑这些问题，而且恐怕他们会迷失在复杂性中（是的，这是一个真正的问题！）。

因此，让我们删除与Linq-to-Sql的任何直接关联，因为我不想要一种依赖于L2S甚至EF的工作方式的解决方案。我的意图是抽象化正在使用的数据访问技术，以便我可以根据需要进行更改，而无需对业务层中的使用方代码进行附带更改。过去，我通过向业务层提供要使用的IRepository接口来实现这一目标。也许这些应该被命名为IUnitOfWork，或者更像是IDataService，但目标是相同的。这些接口通常公开一些方法，例如Add，Remove，Contains和GetByKey。

这是我的情况。我有三个数据库可以使用。一个是DB2，它包含客户（特许经营者）的所有业务信息，例如其信息及其产品，订单等。另一个，SQL Server数据库包含其财务历史记录，而第三个SQL Server数据库包含特定于应用程序的信息。前两个数据库由多个应用程序共享。

通过我的应用程序，客户可以输入/上传给定时间段内的财务信息。输入后，我必须执行以下步骤：

1.根据一组静态规则验证输入的数据。例如，数据必须包含合法的客户ID值（在上传的情况下）。这需要在DB2数据库中进行查找，以验证提供的客户ID是否存在并且是最新的。
2.Next，我必须根据第三个（SQL Server）数据库中包含的一组动态规则来验证数据。一个示例可能是给定值不能超过另一个值的某个百分比。
3.一旦验证成功，我就将数据持久保存到包含财务数据的第二个SQL Server数据库中。
一直以来，我的代码必须具有松耦合的依赖关系，因此我可以在单元测试中模拟它们。

作为分析的一部分，我知道我要使用三个不同的数据存储，并且大约有六个（现在）我正在使用的实体。笼统地说，我假设我的应用程序中将有三个DataContext，每个数据存储一个，而相应的数据上下文公开了这些实体。

然后，我可以为每个实体创建一个单独的I {服务存储库|服务|服务}，该实体将由我的业务逻辑使用一个具体的实现，该实现知道要使用的数据上下文。但是，随着实体数量的增加，这似乎是一个冒险的命题，单个存储库| UoW |服务类型的数量也会增加。

然后，以我的验证逻辑为例，该逻辑可与多个实体并因此与多个数据上下文一起使用。我不确定这是否是最有效的方法。

我还没有提到的另一个要求是在报告方面，在该方面我需要在数据存储上执行一些复杂的查询。截至目前，这些查询一次将仅限于单个数据存储，但是有可能我可能需要具有将多个来源的数据融合在一起的能力。

最后，我正在考虑将前两个（共享）数据库的所有数据访问内容提取到各自项目中的想法，并且一直在将WCF数据服务视为一种可能的方法。这将为我为使用此数据的任何应用程序提供一致方法的基础。

这如何改变您的想法？

Answer 1

看这个SO answer。我认为它显示了您想要的简化模型。 IQueryable<T>确实是我们的新存储库：-)。 DataContext和ObjectContext是我们的工作单位。

更新2：

Here is a blog post描述您可能正在寻找的模型。

更新3

将共享数据库隐藏在服务后面是明智的。这将解决几个问题：


这将使数据库对服务私有，这使得在需要时更容易更改实现。
您可以将所需的验证逻辑（用于数据库1）放入该服务，并可以在该项目中为该验证逻辑创建测试。
访问该服务的客户端可以假定该服务及其验证逻辑是正确的。


这样的结果是您的应用程序会将数据发送到服务以对其进行验证。调用服务以获取数据。查询其自己的私有数据库（数据库3），然后将三个数据源的数据本地结合在一起。我从来都不喜欢使用跨数据库甚至跨服务器（根据您的情况）进行数据库调用，然后让数据库将所有内容连接在一起。事务将被提升为分布式事务，并且很难预测服务器将交换多少数据。

当您在服务背后抽象共享数据库时，事情会变得更加容易（至少从应用程序的角度来看）。您的应用程序调用它信任的服务，这限制了该应用程序中的代码量和测试量。您仍然想模拟对此类服务的调用，但这很容易。它还应解决对多个数据源进行验证的问题。

验证始终是困难的部分。我对Validation Application块非常熟悉，并喜欢它的灵活性。但是，它不是一个简单的框架，但是您可能会窥视到它可以做什么。例如，我写了几篇有关与O / RM工具和Validation Application Block中的how to 'embed' a context（DataContext / WorkUnit中的上下文）集成的文章。