EF6与分层体系结构

Question

我知道这个问题一次又一次地回来，我读了很多关于它的文章，但是我找不到答案。我没有太多关于asp.net mvc的经验，但我已经使用ef、存储库和uow模式做了一个项目。在我的上一个项目中，我有几个层次，包括：

• Web (project )
• BLL (我的业务层)
• DAL (数据访问，附带ef上下文、存储库和uow实现)

现在，我想用EF6启动一个新项目。我读到uow不需要，我想试一试。到目前为止，我知道您必须将您的dbContext传递给您的服务，将您的服务传递给您的控制器，对吗？那么，您必须在服务层中也有一个引用entityFramework吗？还是对的？而且，由于身份实现，您也需要在UI中引用entityFramework。那么，层又有什么意义呢？如果我读了这个微软指南，我只需要做一个文件夹到我的DAL和其他层?！在我看来不对..。但也许吧？

我也读过这篇帖子，他们似乎证实了我的观点。如果您在UI中添加统一并对其进行配置，它只是在您的UI中更多地引用:)

所以我的问题是，如果你必须现在开始一个新的项目，用EF6，asp.net MVC5，你会怎么做？我想做图层是对的吗？还是只继续我的MVC项目？

我错过的一件事是一个教程，它解释了如何从microsoft 5模板开始，并使用层、解耦标识和最终在我的UI中没有引用来转换它。这东西存在吗？

Answer 1

这里没有银弹。有些人用一种方式，有些-另一种。取决于所需的抽象级别。我以前有三个项目：

1. 网站
2. 核心/业务(服务)
3. 模型/EF/域(实体框架上下文和模型)

如果Web有域或EntityFramework的引用，这是很好的。Web可以返回EF模型(只是为了避免代码重复)。如果需要更复杂的模型，则创建ViewModel。

我不建议使用UoW或存储库模式(除非您真的需要它)。EF上下文已经是UoW模式的一个实现。如果您想用实体框架实现存储库模式，不要在接口中公开任何与EF相关的内容，例如SaveChanges()、Dispose()，因为在本例中，您不会利用存储库模式的好处。

因此，这就是我如何建立典型的中小型ASP.NET MVC + EF网站。但正如我所说，一切都取决于所需的抽象级别。抽象级别与编写代码的数量成正比。所以，先想一想，保持简单。祝好运。

Answer 2

我非常喜欢存储库模式，因为它从客户端应用程序中抽象出实际的数据存储。前端不需要知道数据来自何处，它既可以来自诸如实体框架之类的框架，也可以是一个简单的转换后的DataTable。这是一种通用方法，如果存储库框架通过了所有测试，则可以将其重用到未来的所有项目中。这个教程为您提供了一个关于如何实现UOW和Repository模式组合的很好的视图。

基本上，您的客户端应用程序(=MVC)不需要对实体框架的引用，对于服务层来说，有一个引用就足够了。然后使用此引用将您自己的DbContext传递到存储库层(假设您已经为实体框架编写了存储库层)，理想的方法是通过DI容器(如Unity )。

当然，对于是否在EF中使用存储库模式(因为它已经是数据库的抽象)进行了大量讨论，但我认为它是创建和使用可重用组件的一个很好的练习。