EF6 和分层架构

Question

我知道这个问题一次又一次地出现，我阅读了很多关于它的内容，但我找不到我的问题的答案。 我在 asp.net mvc 上没有很多 exp，但我已经使用 ef、repository 和 uow 模式做了一个项目。 在我的上一个项目中，我有几个层次，包括：

• Web（项目 MVC）
• BLL（我的业务层）
• DAL（数据访问，带有 ef 上下文、存储库和 uow 实现）

现在，我想使用 EF6 开始一个新项目。我读到不需要 uow，我想试一试。 到目前为止，我知道您必须将 dbContext 传递给您的服务，并将您的服务传递给您的控制器，对吗？ 所以你的服务层也必须有一个对 entityFramework 的引用吗？还对吗？ 而且由于身份实现，您也需要在 UI 中引用 entityFramework。 那么 layer 有什么意义呢？ 如果我读到这个microsoft guide，我所要做的就是为我的 DAL 和其他层创建一个文件夹？！对我来说似乎不对......但也许？

我也读过这个post，他似乎证实了我的观点。而且，如果您在 UI 中添加统一并对其进行配置，则它只会在您的 UI 中更多参考 :)

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

我想念的一件事是一位教程，他一步一步地解释如何从 microsoft MVC 5 模板开始，并使用层、解耦标识以及最后在我的 UI 中没有 ef ref 对其进行转换。这东西存在吗？

Answer 1

这里没有灵丹妙药。有些人以一种方式做到这一点，而另一些人则以另一种方式做到这一点。取决于所需的抽象级别。我曾经有 3 个项目：

1. 网络
2. 核心/业务（服务）
3. 模型/EF/域（实体框架上下文和模型）

如果 Web 引用了 Domain 或 EntityFramework 也没关系。 Web 可以返回 EF 模型（只是为了避免代码重复）。如果您需要更复杂的模型，您可以创建 ViewModel。

我不推荐使用 UoW 或 Repository 模式（除非你真的需要它）。 EF 上下文已经是 UoW 模式的实现。如果您想使用实体框架实现存储库模式，请不要在接口中公开任何与 EF 相关的内容，例如SaveChanges()、Dispose()，因为在这种情况下，您将无法利用存储库模式的优势。

这就是我构建典型的中小型 ASP.NET MVC + EF 网站的方式。但就像我说的，一切都取决于所需的抽象级别。抽象级别与需要编写的代码量成正比。因此，请先考虑并保持简单。祝你好运。

Answer 2

我非常喜欢存储库模式，因为它从您的客户端应用程序中抽象出您的实际数据存储。前端不需要知道数据是从哪里来的，它既可以来自Entity Framework等框架，也可以是一个简单的转换后的DataTable。这是一种通用方法，如果您的存储库框架已通过所有测试，您可以将其重用于您未来的所有项目。这个tutorial 让你很好地了解如何实现 UOW 和 Repository 模式的组合。

基本上，您的客户端应用程序 (=MVC) 不需要引用实体框架，您的服务层有引用就足够了。然后，您可以使用此引用将您自己的 DbContext 传递给存储库层（假设您已经为实体框架编写了一个存储库层），最好是通过像 Unity 这样的 DI 容器。

当然，关于是否将存储库模式与 EF 一起使用存在很多讨论（因为它已经是数据库的抽象），但我认为这是创建和使用可重用组件的一个很好的练习。