Entity Framework 6，我应该使用存储库模式吗？答案

【问题标题】：Entity Framework 6 , Should I use repository pattern?Entity Framework 6，我应该使用存储库模式吗？
【发布时间】：2014-11-27 15:40:49
【问题描述】：

我对 Entity Framework 还是很陌生，仍然在努力解决它。这么多不同的示例和解释，我不知道该怎么办？

我有几个问题：

在我当前的应用程序中，我使用了一个由以下组成的模式：

对于每个 from ，我声明一个新的工作单元。所以当我进行 Savechanges 时，只有相关项目受到影响。

对于复杂的业务逻辑，我在 Repository 中为每个类编写我的方法例如：

但是最近我发现 Entity Framework 6.0 ：

所以问题是：

谢谢

【问题讨论】：

DbSet 不是存储库，除非 EF 可以“按原样”使用您的域对象。即使这样，它公开 IQueryable 的事实也违背了存储库模式的目的。简而言之，Repository 是一个原则，它的实现不是 DbSet，但实现可以使用 EF 作为内部细节。
谢谢，那是我弄错了，抱歉显示正确的路径。

【解决方案1】：

首先，尝试将您的 DbContext 视为单例对象是一个坏主意，因为您无法在操作中管理事务。您必须为每个操作实例化您的 DbContext。

其次，尝试将您的“数据层关注点”与“业务关注点”分开。例如：

一种方法：从一个库存位置移除一件物品，将其移动到另一个位置，然后减少旧位置的数量

我认为您正在为每个用例编写存储库方法，这与数据层无关。您的存储库只需要了解持久化和检索对象。以另一种方式，您的存储库方法只是 CRUD 方法。您的业务层将使用此方法来执行业务逻辑。

【讨论】：

感谢 Hadi 的细致回答。关于 DbContext ，我也感觉每次都需要单独的 DbContext ，因为事务。关于第二个问题，您是说我应该保留我的存储库，并在其中编写业务逻辑方法吗？你能给我看一个concerte示例示例代码吗？
以我个人的经验，使用 DbContext 的最佳实践是每次在操作中实例化它（不要忘记使用 'Using' 块以避免内存泄漏）。关于第二个问题，我的意思是您bold不应该bold 在您的存储库中编写业务逻辑。例如，您的存储库中应该只有简单的 Update() 方法，然后您的业务逻辑方法将使用此更新来“从一个位置移动库存”[链接]efgenericrepository.codeplex.com/SourceControl/…
对不起，我上次的评论有问题，现在它不允许我编辑它。正确链接：EF Generic Repository Pattern
感谢哈迪，在检查链接并重新阅读您的回复后，它更有意义，