MVC3和Entity Framework

Question

我的问题很简单：在MVC3项目的Web应用程序中，将.edmx文件放置在模型文件夹中是否是一种好的做法？

- Jorge

Answer 1

我的答案很简单，不要将表现层（整个MVC应用程序）与数据访问逻辑和数据建模混淆。

在Visual Studio解决方案中至少有4个项目，从底层到顶层：

1 - ProjectName.Interfaces（类库，实体的接口）；

2 - ProjectName.DAL（类库，唯一一个允许知道EF被使用的项目，POCO实体使用另一个文件实现项目1的接口，其中重新声明相同的对象使用部分类...）；

3 - ProjectName.BL（类库，业务逻辑，引用上述两个项目1和2）；

4 - ProjectName.Web（ASP.NET MVC应用程序，表现层，引用两个项目1和3但不是2）；

这样做当然是为了简化事情，根据我的经验，这是一个坚固的设计，对于非常小的项目来说有点过度设计，但在长期内会得到回报。

在我看来，MVC中的M，即模型，不是数据模型，不是EF，也不是ORM绑定到特定的数据库引擎。

当然，这个答案是主观的，并基于我的个人经验;-)

- Davide Piras

---

关于MVC中的M，更进一步来说应该是Presentation Model，它代表了展示给最终用户所需的知识和信息。毕竟，ASP.NET MVC只是一个UI框架，不多也不少。 - Scott Mitchell

是的，我看到很多项目都将M强制指定为数据模型，并视其为数据模型。 :-( - Davide Piras

在3层架构中，业务层是连接表示层和数据访问层的桥梁。它是应用程序的核心，并处理所有的业务逻辑和数据操作。其主要功能包括数据校验、处理和存储，以及与数据库和其他外部系统的交互。通过将业务逻辑从用户界面和数据库中分离出来，可以提高应用程序的可维护性和扩展性。 - balexandre

非常好的答案，Davide。我还可以补充一点，我通常会为单元测试添加一个项目。因此，我通常会使用ProjectName.Interface、 ProjectName.Data、 ProjectName.BL、 ProjectName.Web 和 ProjectName.Test。在测试项目中，我会为每个项目创建一个文件夹。当然，测试项目必须引用所有项目。 - Kias

在介绍MVC的指南中，需要更加强调MVC中的Model是对View进行建模，而不是Domain。+1。 - Ant P

Answer 2

我完全同意Davide的观点，我只想补充一点，你还应该考虑使用POCO模板生成POCO对象，而不是返回实体框架对象到另一层，因为这会对实体框架产生依赖。

如果你不将其分离到一个单独的项目中，那么在某个不可避免的时刻，你的直接数据访问代码最终会被抛到Web代码中。我经常看到这种情况（我们所有人都曾经有过类似的错误）。

- Adam Tuliper

Answer 3

我认为这并不重要。

我使用CodeFirst，所以我的DbContext类放在Model文件夹中。

实际上，EDMX仅用于代码生成，除此之外它没有太多作用，它不会被部署/发布到服务器上等，所以它的位置并不重要。如果您想要，您可以为EDMX创建另一个文件夹，或将其放在您要求的Model文件夹中。

- Daryl Teo

---

虽然这很重要，但你的 Web 项目中存在一个依赖性，它紧密地耦合了实体框架和特定实现的数据访问技术，这可能在将来某个时刻会发生变化，例如不同版本、不同技术或没有实体框架等。这会在各处散布数据访问代码，成为 Web 应用程序的一种瘟疫。 - Adam Tuliper

但这与EDMX文件无关，它只是模型规范...在编译时生成其他文件并进行部署。但EDMX的位置是无关紧要的。 - Daryl Teo

这与此有很大关系。它们将在edmx文件所在的项目中生成，如果您尝试以其他方式进行操作，将会很混乱。 - Adam Tuliper

好的，我认为我们对问题的解释有所不同。是的，Davide的答案是在应用程序中构建项目的好方法，我也给了他一票。然而，如果我们正在讨论一个单独的项目（正如问题所示），那么edmx文件在该项目中的位置就无关紧要了。这就是我的回答。 - Daryl Teo

有些人在这里变得挑剔，试图教授“更正确”的方法 - 但是观点已经被接受了：） - Adam Tuliper