MVC3和实体框架

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

我的回答很简单，不要搞表达层（整个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，Model，不是数据模型，不是EF，是不是有ORM绑定到特定的数据库引擎。

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

我同意Davide在这里完全我只是想补充一点，你还应该考虑使用POCO模板来生成poco对象，而不是返回实体框架对象到另一个层，因为它然后放置在实体框架的依赖。

在某些不可避免的情况下，如果您不把它们分解到一个单独的项目中，那么您的直接数据访问代码就会丢到您的Web代码中。我一直都在看（这个时候我们一直都很愧疚）

我不认为这很重要。

我使用CodeFirst，所以我的DbContext类去模型文件夹。

真的，EDMX只是为了生成代码，除此之外它没有太多的功能，没有部署/发布到你的服务器等等。所以，它停留的地方并不重要。如果需要，可以为EDMX创建另一个文件夹，或者按照您的要求将其放入模型中。