工作单元和存储库模式对于大型项目非常有用吗？

Question

我正在使用 ASP.NET Webforms + EF4 启动一个新的 Web 项目。我正在尝试按照本教程应用具有工作单元模式的存储库模式： http://www.dotnetage.com/publishing/home/2011/07/05/6883/the-repository-pattern-with-ef-code-first-dependeny-injection-in-asp- net-mvc3.html

我想我明白了，但我的问题是，当我在模型中创建一个新对象时，我是否还必须在 Unit Of 的 IDALContext 中定义该对象 工作？这不是快速发展的断手吗？此外，如果您与多个开发人员合作，并且您不希望其他开发人员看到您的 DAL，您该如何管理呢？因为据我了解，在这种模式中，当您在模型中创建新对象时，您还必须在本教程的 IDALContext 中定义它。抱歉我对此感到很困惑。

Answer 1

您应该考虑“命令/查询对象”作为替代方案，您可以在该领域找到很多有趣的文章，但这里有一些不错的文章：

https://bigmachine.io/2014/03/04/repositories-and-unitofwork-are-not-a-good-idea/
https://www.dotnetcurry.com/patterns-practices/ 1461/command-query-separation-cqs

您将坚持每个命令使用一个命令对象来启用简单事务，从而避免对 Unit Of 的复杂性的需要工作模式。

但是，如果您认为每个查询一个 Query 对象对您来说太过分了，那么您很可能 100% 正确。通常，您可能会选择从“FooQueries”对象开始，它本质上是一个存储库，但仅用于查询。 “Foo”可能是 DDD 意义上的“域聚合”。

然后您可能会发现单个查询对象稍后是有价值的。

与大多数事情一样，您必须逐个系统地考虑。

Answer 2

软件设计模式旨在在正确的上下文中解决特定问题，如果使用不当，它们会在不提供任何价值的情况下导致额外不必要的复杂性。

那么，存储库模式旨在解决哪些问题解决？

1- 最小化重复查询逻辑：在大型应用程序中，您可能会发现许多复杂的 LINQ 查询在几个地方重复。如果是这种情况，您可以使用存储库模式来封装这些查询并最大程度地减少重复。

2-更好的关注点分离：想象一个复杂的查询，用于获取给定类别中最畅销的课程，其中涉及急切加载、加入、分组、过滤等。

当您在您的应用程序中实现如此大的复杂查询时，服务/控制器，你最终会得到胖服务/控制器。这些类变得很难进行单元测试，因为它们需要大量嘈杂的存根。您的单元测试变得冗长、臃肿且难以维护。

如果您遇到这个问题，也许您可​​以考虑使用存储库模式。在此示例中，我们可以封装复杂的查询以获取存储库中的最畅销课程：

courseRepository.GetTopSellingCourses(int categoryId, int count);

这样，您的服务/控制器将不再处理急切的加载、加入、分组等。相反，它们将委托给存储库。请记住，急切加载、加入和分组等都是查询逻辑，属于您的数据访问层，而不是您的服务或表示层。

3- 将应用程序架构与持久性框架解耦：当您直接在应用程序中使用实体框架类（例如 DbContext、DbSet 等）时，您的应用程序与实体框架紧密耦合。如果您计划在将来的某个时候切换到不同的 O/RM，甚至是具有不同模型的较新版本的实体框架，您可能必须修改应用程序的许多部分，这可能会导致应用程序中出现新的错误。您可以使用存储库模式将应用程序架构与持久性框架（例如实体框架）分离。这样，您就可以自由地更改为不同的 O/RM，同时将对应用程序的影响降至最低。

观看此视频了解更多详情：

https://youtu.be/rtXpYpZdOzM

Answer 3

Martin Fowler 将存储库的角色描述为：“存储库在域和数据映射层之间进行中介，就像内存中的域对象集合一样”。从这个意义上讲，Entity Framework 4.1 公开的是一个存储库。此外，EF 还具有内置的工作统一性。因此，我的建议是忽略您在问题中提到的博客文章。

像这样的代码不仅无用或毫无价值，而且很危险，因为代码中没有添加任何好处，而是依赖！

public interface IUnitOfWork:IDisposable
{
    int SaveChanges();
}

public interface IDALContext : IUnitOfWork
{
    ICategoryRepository Categories { get; }
    IProductRepository Products { get; }
}

要回答您的问题，需要在域和数据映射层之间进行一些抽象，就像内存中域对象集合一样，对于“大”项目来说是必须的。在幕后拥有一个 UnitOfWork 机制可以帮助您将业务逻辑与对某些数据访问抽象的访问分离。

TL;TR;
Repository 和 UnitOfWork 可以帮助您，但不要像给定的博客文章中那样应用它。

Answer 4

现在，第一个问题应该是，为什么我需要存储库或工作单元模式？我难道不能只使用控制器中的 EF 上下文，拥有直接编写我需要查询并返回数据？
答案：你可以，但背后的真正意图是可测试性，从而获得更高质量、更易于维护的代码。如果您将数据访问分开并将其集中在一个地方，则可以在测试期间模拟它。这允许您对控制器中定义的逻辑进行单元测试，而无需有效写入数据存储。

在开始工作单元之前，只需查看一下存储库模式。这基本上抽象了给定实体的数据访问。因此，您可以定义 Filter()、All()、Update(..)、Insert(..)、Delete(...) 以及 Save() 等方法。实际上，其中大多数都可以很容易地抽象为 BaseRepository 类，这样最终您只需在极少数具有特殊行为的情况下创建一个新的存储库。否则它会像 BaseRepository 一样。 personRepo = new BaseRepository() 或 BaseRepository

; addressRepo = new BaseRepository

() 等

为什么需要工作单元？
工作单元代表在某个周期内完成的所有操作，在 Web 环境中通常是每个 Http 请求。这意味着当新请求输入时，您实例化一个新的工作单元，添加新内容，更新或删除它，然后通过调用 .save() 或 “提交”更改>.commit()..无论如何。实际上，如果您仔细查看实体框架 DbContext（或 ObjectContext），您会发现它们已经代表了某种工作单元。
但是，如果您想进一步抽象它，因为您不一定希望在控制器类中拥有 EF 上下文（记住：可测试性），那么您可以创建一个 UoW 来对您的存储库进行分组，并确保它们都共享相同的 EF上下文实例。您也可以通过 DI 容器（依赖注入容器）来实现后者。

对于您的问题：它在大型项目中有用吗？：
当然，尤其是在大型项目中。这一切都是为了保持职责分离（数据访问、业务逻辑、领域逻辑），从而使事情可测试。