EF6和分层架构

Question

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

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

现在，我想用EF6开始一个新项目。 我读到uow不需要，我想尝试一下。 到目前为止，我知道您必须将dbContext传递给您的服务以及您的控制器服务，对吗？ 那么你必须在服务层中有一个对entityFramework的引用吗？ 还是吗？ 而且由于身份实现，您还需要在UI中引用entityFramework。 那么层的重点是什么呢？ 如果我阅读这个微软指南 ，我只需要为DAL和其他图层创建一个文件夹？ 对我来说似乎不对......但也许吧？

我也读了这篇文章 ，似乎证实了我的观点。 如果你添加统一并在你的UI中配置它，它在你的UI中只是更多的参考:)

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

我想念的一件事是一个tuto，它解释了如何从微软MVC 5模板开始，并用图层转换它，解耦身份，最后在我的UI中没有ef ref。 这件事存在吗？

Answer 1

这里没有银弹。 有些人单向做，有些人做 - 另一个。 取决于所需的抽象级别。 我曾经有过3个项目：

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

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

我不建议使用UoW或Repository模式（除非你真的需要它）。 EF上下文已经是UoW模式的实现。 如果要使用Entity Framework实现存储库模式，请不要在接口中公开与EF相关的任何内容，例如SaveChanges（），Dispose（），因为在这种情况下，您将不会利用存储库模式的好处。

这就是我将如何构建典型的中小型ASP.NET MVC + EF网站。 但就像我说的，一切都取决于所需的抽象级别。 抽象级别与写入所需的代码量成比例。 所以先考虑并保持简单。 祝好运。

Answer 2

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

基本上，您的客户端应用程序（= MVC）不需要引用实体框架，您的服务层就足以拥有引用。 然后使用此引用将您自己的DbContext传递给存储库层（假设您已为Entity Framework编写了存储库层），理想情况下通过像Unity这样的DI容器。

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