MVC3和实体框架

Question

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

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);

这当然是为了简化事情,根据我的经验,这是一个坚实的设计,对于非常小的项目有点过分,但从长远来看是有回报的.

在我看来,M的MVC,Model,不是数据模型,不是EF,不是ORM绑定到特定的数据库引擎.

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

关于MVC中M的进一步观点......它是*Presentation*Model.它是表示向最终用户*显示屏幕所需的知识和信息的模型.毕竟,ASP.NET MVC是一个UI框架,仅此而已. (13认同)
@Jorge http://stackoverflow.com/questions/7510396/business-layer-in-3-tier-architecture/7510526#7510526 (3认同)
伟大的答案Davide.我可以补充一点,我通常会为单元测试添加一个项目.所以我通常使用ProjectName.Interface,ProjectName.Data,ProjectName.BL,ProjectName.Web和ProjectName.Test.在测试项目中,我将为每个项目创建一个文件夹.当然,测试项目必须参考所有项目. (3认同)
是的,我看到很多项目,M被迫成为数据模型.:-( (2认同)

Answer 2

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

在某些不可避免的情况下,如果您不将其整合到一个单独的项目中,您的直接数据访问代码最终将被抛入您的Web代码中.我一直都看到它(我们在某个时候都对此感到内疚)