在使用Entity Framework时，我是否需要统一工作和存储库模式？

Question

所以在我的工作中，我被指向http://www.codeproject.com/Articles/990492/RESTful-Day-sharp-Enterprise-Level-Application#_Toc418969121并被告知要学习这些模式并在我的解决方案中实施它们。

令我感到困惑的是，这些东西都在实体框架6之前，根据我的理解，Unity of Work用于通过将查询分组在一起来优化数据库性能。由于EF6已经进行了这些优化，我还应该实现这些层吗？我认为层次有助于数据源的模块化和切换。这是否意味着EF6太复杂而无法实现这些模式，是否可以直接使用ADO.Net或类似的东西？

编辑：我注意到这个添加的图层允许使用模拟数据源。不确定这是多么有用，因为需要添加另一层apstraction

Answer 1

＆＃34;工作单元用于通过将查询分组在一起来优化数据库性能。＆＃34; - 这不正确。工作单元将相关操作收集到一起，然后作为一个整体提交或回滚。它跟踪对对象所做的更改，以便可以自动推断并代表您执行所需的数据库操作。

使用Entity Framework时，可以使用它从模型创建DbContext。那个班级既是知识库又是工作单元，所以你不必做任何特别的事情。当项目变得如此之大以至于DbContext变得更加沉重时，事情变得更加复杂。

Answer 2

Repository用于从数据源中抽象出您的应用程序，但由于EntityFramework本身实现了这种模式，并且您可以无缝地更改数据源，因此无需再添加一层抽象。

您只需限制EF种可能性，同时创建GenericRepository<T>之类的内容。尽管如此，即使您实现了这样的图层，您仍然无法通过其他库替换EF而无需更改代码。 （例如，EF为NHibernate编写的某些查询将失败。

不要在应用程序的任何地方使用DbContext（至少在UI代码中），使用数据访问层（具有业务依赖方法的服务或以这种方式提供的服务）。

即使在使用某些云数据存储（EF无法无缝处理）的情况下，该层也不是必需的，最好分开引入类和显式使用它们，因为你不能将db和cloud交互融入一个抽象中，它会在某个时候开始泄漏。

Answer 3

实体框架本身就是一个UnitOfWork / Repository模式。如果您需要从EF中抽象自己，那么您可以使用自己的UoW / Rep模式在EF上实现一个层。

如果你想在你的项目中的某个点替换EF，那就很好。

缺点？我认为在EF之上构建UoW可以为您提供冗余架构，并且最终会为可能永远不会改变的内容编写更多代码。

在我目前的项目中，主要结构很常见，有一个数据层（带有实体的子层），用于EF，逻辑层（我放置所有业务逻辑）和视图层（它可以是web） ， 管他呢）。使用该结构，我直接在逻辑层中调用EF。