EF6和分层架构

Question

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

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

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

我也读过这个post，他似乎证实了我的意见。如果你添加统一并在你的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。这是一种通用方法，如果您的存储库框架已通过所有测试，您可以将其重用于所有未来的项目。这个tutorial为您提供了如何实现UOW和Repository模式组合的良好视图。

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

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