使用DI重构DAL，以便以后能够更改DAL

Question

我们目前拥有的是一个相对较旧的代码库，使用EntitySpaces (并不重要，但它是一个ORM，这是一个很好的在过去的日子里使用，但根据我最近的EntityFramework经验，它不再是太多的使用ORM直接访问一个数据库。我现在面临着更改应用程序的许多部分的需要，这些应用程序目前直接依赖于EntitySpaces对象。这不太好，但现在是这样的。我的总体想法是引入一个层，该层引入中立的、持久化的对象，编写某种存储库接口来获取、更新这些对象，并编写仍然使用EntitySpaces的(首先)实现。然后，我可以重构当前直接使用EntitySpaces的所有类和组件。希望这将使我能够在以后更改存储库实现，以使用webservice或EntityFramework。

以下是我的问题/不安全感：

通常，我希望有一个存储库对象在某处，还是为组件提供一个返回(特定)存储库的工厂更好？也许我甚至可以为不同类型的对象将存储库划分到不同的接口中，这可能会导致一些20小时的接口。

假设我有UI组件，这些组件现在在数据库上执行许多操作。如果我重写它们来针对存储库工作，那么最好是“给”这些组件一个存储库对象，还是以一种它们甚至不需要知道某个地方存在存储库的方式重写这个UI组件？假设有一个对话框，它允许您从数据库加载一个Part，修改它并将其发回。这可以看作是某种PartEditor接口，当用户点击Update或Delete按钮时，只需要回调即可使用。

您会使用DI框架来完成这个任务吗？这个应用程序比较大，我认为大约是800 k loc，没有重用公司范围的库。另一种方法是在不使用DI框架的情况下对所有组件隐藏具体的类，以避免引入新的问题。对于使用我的新抽象的组件来说，这不应该有什么区别，因为这些组件的编写方式应该不需要知道所使用的DI框架，对吗？

我知道这是相当抽象的，也许很难回答，但我希望其他人对这类任务有一些经验。我感谢任何指点。至于使用哪个DI框架的问题，我完全开放。

Answer 1

通常，我希望有一个存储库对象在某处，还是为组件提供一个返回(特定)存储库的工厂更好？也许我甚至可以为不同类型的对象将存储库划分到不同的接口中，这可能会导致一些20小时的接口。

我将为每个聚合根创建一个存储库。这使得维护和测试代码变得更容易。

假设我有UI组件，这些组件现在在数据库上执行许多操作。如果我重写它们来针对存储库工作，那么最好是“给”这些组件一个存储库对象，还是以一种它们甚至不需要知道某个地方存在存储库的方式重写这个UI组件？假设有一个对话框，它允许您从数据库加载一个部件，对其进行更改并将其发回。这可以看作是某种PartEditor接口，当用户点击Update或Delete按钮时，只需要回调即可使用。

为此，您应该使用存储库模式。您可以在批处理方法的存储库中切换到DataAdapter (如果您已经度量了那些scenarious的EF性能太差)。这就是为什么抽象概念如此伟大。您可以在不影响代码其余部分的情况下，在所需的实现之后安装该实现。

您会使用DI框架来完成这个任务吗？这个应用程序比较大，我认为大约是800 k loc，没有重用公司范围的库。另一种方法是在不使用DI框架的情况下对所有组件隐藏具体的类，以避免引入新的问题。对于使用我的新抽象的组件来说，这不应该有什么区别，因为这些组件的编写方式应该不需要知道所使用的DI框架，对吗？

在使用数据库时，我确实使用了DI框架。这使得让所有存储库共享相同的连接和事务变得更加容易(而不会升级到分布式事务)。

您可以在这里读到我为EF所做的一个实现：http://blog.gauffin.org/2013/01/repository-pattern-done-right/

Answer 2

通常，我希望有一个存储库对象在某处，还是为组件提供一个返回(特定)存储库的工厂更好？也许我甚至可以为不同类型的对象将存储库划分到不同的接口中，这可能会导致一些20小时的接口。

我建议您创建一个通用存储库来隐藏域到数据的转换(或者使用OR/M或其他什么)，然后使用控制反转来实例化它。

// The factory hides who's the actual 
// repository implementation. In your case, it could be 
// EntityFrameworkRepository<T> or EFGenericRepository<T>
GenericRepository<Order> orderRepo = RepositoryFactory.Create<Order>();

存储库可能具有以下方法：

• 添加。
• GetById。
• 删除。
• GetByCriteria(表达式树)(例如，queryable => queryable.Where(...))。此方法可以接受输入参数为Expression<Func<IQueryable<T>, IQueryable<T>>>。实体框架和NHibernate将允许您以这种方式实现它。

使用这种方法--泛型存储库--您可以避免使用该20、30个存储库，此外，您还拥有一个实现OR/M特定任务的基本存储库实现，以避免在代码库中传播特定的依赖关系！

假设我有UI组件，这些组件现在在数据库上执行许多操作。如果我重写它们来针对存储库工作，那么最好是“给”这些组件一个存储库对象，还是以一种它们甚至不需要知道某个地方存在存储库的方式重写这个UI组件？假设有一个对话框，它允许您从数据库加载一个部件，对其进行更改并将其发回。这可以看作是某种PartEditor接口，当用户点击Update或Delete按钮时，只需要回调即可使用。

UI不应该知道存储库的情况。它应该是业务域，诸如UI和存储库之类的中介。

您会使用DI框架来完成这个任务吗？这个应用程序比较大，我认为大约是800 k loc，没有重用公司范围的库。另一种方法是在不使用DI框架的情况下对所有组件隐藏具体的类，以避免引入新的问题。对于使用我的新抽象的组件来说，这不应该有什么区别，因为这些组件的编写方式应该不需要知道所使用的DI框架，对吗？

是的，使用DI/IoC框架。不要回避不可避免的问题，也不要重新发明轮子- -这比使用第三方库更大的问题！我建议您使用温莎城堡，因为它的成熟性、健壮性和功能丰富的框架。