.net - Asp Net Mvc 中的 SOLID 原理、Repository 模式和 EntityFramework 缓存

Question

我有一个使用纯色图案的 Visual Studio 解决方案。我有一个 IRepository(Crud 实现)、IDbFactory(由存储库使用)、IUnitOfWork。我也有服务，他们使用存储库来构建自定义查询和复杂的数据库操作。我也在 Ninject 中使用 IoC 模式。在 web mvc Controller 中，我只使用服务来访问数据库。存储库接收构建 EntityFramework 上下文的 IDbFactory。我有一些问题:

• 在服务中，当我必须访问两个表以连接它们时，我应该使用两个存储库，调用它们的 GetAll() 方法。在这种情况下，两个存储库应共享相同的 EntityFramework 上下文。
• 前面的案例表明 DbContext 应该由所有存储库共享，因此我可以将 IQueryables 加入来自不同存储库的服务中。
• 为了实现这个目标，我在 IoC 容器中配置了单例范围内的 DbContext。所以每个存储库共享相同的 DbContext。
• 这个解决方案的问题是 DbContext 有一个缓存。因此，当外部进程(与 Web 项目不同)更改我的数据时，DbContext 不会意识到这一点，并且 Web 项目有时不会显示真实数据。
• 我读到过在每个存储库调用中销毁 DbContext，但我不能这样做，因为每个存储库都应该使用相同的 DbContext

我的项目结构有问题吗？这是我必须在存储库层修复的东西吗？我该怎么办？该项目处于开发阶段，因此我可以更改数据访问架构。我喜欢在 Controller 中使用 IQueryables，这样用户在数据网格中的过滤器就会产生 sql 查询。

Answer 1

好吧，就您在这里陈述的问题而言，您的项目结构没有任何问题。问题源于使用 Singleton 作用域。您应该为 Web 应用程序使用 Request 范围。这可确保您获得每个请求的新上下文，因此不同请求甚至不同客户端之间不会出现重叠，这可能非常危险。

也就是说，您的项目结构设计过度。存储库/工作单元模式旨在用于低级数据访问。 ORM，如 Entity Framework ，处理所有这些，事实上， Entity Framework 已经实现了这些模式。 DbContext 是工作单元，每个 DbSet 都是一个存储库。在此之上添加您自己的存储库/工作单元层是多余且不必要的。您的服务应该直接使用您的 Entity Framework 上下文。即便如此，拥有多个服务也可能是不必要的，这取决于它们的作用。如果它们都使用相同的数据源(即 Entity Framework 上下文)，特别是如果它们都使用相同 Entity Framework 上下文，那么它们真的应该全部整合为一个。

在我自己的个人项目中，我使用一个“服务”类，每个唯一的上下文实例都有通用方法。通用方法让我可以使用属于该上下文的任何实体，而无需新建“服务”类的其他实例。通过确保一切都实现一个或多个接口(interface)并使用依赖注入(inject)来满足接口(interface)约束，底层数据层被完全分解出来。我有一个 series of posts如果您有兴趣，那会更详细。

我说这一切是因为您似乎过分关注模式和“最佳实践”。这些只是指南。它们就像自行车上的训练轮。它们都基于良好代码设计的各种原则。学习并应用原则，不要担心选中某种设计模式列表中的所有框。

有趣的是，Stack Overflow 的核心代码库实际上避开了一些模式(甚至是依赖注入(inject))，因为它们非常专注于原始性能，而一些设计模式在应用时实际上会阻碍性能。关键是应用程序的设计方式应基于特定应用程序的需求。设计模式应仅在符合您的应用程序需求的情况下应用，而不仅仅是因为您认为您应该这样做。