0

我们目前拥有的是一个相对较旧的代码库，使用 EntitySpaces（其实并不重要，但它是一个 ORM，在过去很好用，但根据我最近的 EntityFramework 经验，它不再那么重要了）作为用于直接访问数据库的 ORM。我现在需要更改当前直接依赖于 EntitySpaces 对象的应用程序的许多部分。这不是很好，但现在就是这样。我的总体想法是引入一个层，该层引入中性的、不感知持久性的对象，编写某种存储库接口来获取、更新等这些对象，并编写一个仍然使用 EntitySpaces 的（第一个）实现。然后我可以重构所有当前直接使用 EntitySpaces 的类和组件。

这是我的问题/不安全感：

一般来说，我是想让一个存储库对象坐在某个地方还是更好地为组件提供一个返回（特定）存储库的工厂？也许我什至可以针对不同类型的对象将存储库拆分为不同的接口，我猜这会导致一些 20-ish 接口。

假设我有 UI 组件，它们现在对数据库执行大量操作。如果我重写它们以针对存储库工作，是更好地“给”这些组件一个存储库对象，还是以他们甚至不必知道某处有存储库的方式重写此 UI 组件？想象一下，有一个对话框可以让您Part从数据库中加载、更改并发送回。这可以看作是某种界面，当用户点击更新或删除按钮PartEditor时，它可以被给予回调使用。

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

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

4

2 回答 2

2

一般来说，我是想让一个存储库对象坐在某个地方还是更好地为组件提供一个返回（特定）存储库的工厂？也许我什至可以针对不同类型的对象将存储库拆分为不同的接口，我猜这会导致一些 20-ish 接口。

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

假设我有 UI 组件，它们现在对数据库执行大量操作。如果我重写它们以针对存储库工作，是更好地“给”这些组件一个存储库对象，还是以他们甚至不必知道某处有存储库的方式重写此 UI 组件？想象一下，有一个对话框可以让您从数据库中加载一个零件，对其进行更改并将其发回。这可以看作是某种 PartEditor 接口，当用户点击更新或删除按钮时，它可以被给予回调以使用。

您应该为此使用存储库模式。您可以切换到DataAdapter批处理方法的存储库（如果您已经测量到 EF 性能对于这些场景来说太差了）。这就是抽象的伟大之处。您可以根据需要调整实现，而不会影响其余代码。

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

在使用数据库时，我确实使用了 DI 框架。让所有存储库共享相同的连接和事务（无需升级到分布式事务）变得容易得多。

您可以在此处阅读我为 EF 所做的实现：http: //blog.gauffin.org/2013/01/repository-pattern-done-right/

于 2013-02-12T10:14:10.720 回答
1

一般来说，我是想让一个存储库对象坐在某个地方还是更好地为组件提供一个返回（特定）存储库的工厂？也许我什至可以针对不同类型的对象将存储库拆分为不同的接口，我猜这会导致一些 20-ish 接口。

我建议您创建一个通用存储库来隐藏域到数据的转换（使用 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>>>. Entity Framework 和 NHibernate 会让你以这种方式实现它。

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

假设我有 UI 组件，它们现在对数据库执行大量操作。如果我重写它们以针对存储库工作，是更好地“给”这些组件一个存储库对象，还是以他们甚至不必知道某处有存储库的方式重写此 UI 组件？想象一下，有一个对话框可以让您从数据库中加载一个零件，对其进行更改并将其发回。这可以看作是某种 PartEditor 接口，当用户点击更新或删除按钮时，它可以被给予回调以使用。

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

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

是的，使用 DI/IoC 框架。不要回避不可避免的事情，不要重新发明轮子——这比使用第三方库是一个大问题——！我想向您推荐Castle Windsor，因为它的成熟、稳健和功能丰富的框架。

于 2013-02-12T10:31:31.603 回答