ASP.Net MVC是UI层的框架，EF是数据访问的逻辑。
如果在Controller中using DbContext，把查询的结果的对象放到cshtml中显示，那么一旦在cshtml中访问关联属性，那么就会报错。因为关联属性可以一致关联下去，很诱惑人，include也来不及。
如果不using也没问题，因为会自动回收，但是这打开了“潘多拉魔盒”，甚至可以在UI层更新数据，相当于把数据逻辑写到了UI层。
有的三层架构中用实体类做Model，这样也是不好的，因为实体类属于DAL层的逻辑。
没有最好的架构，只有最合适的架构！ 架构不是设计出来的，而是演化出来的！
一、EO
EO（Entity Object，实体对象） 就是EF中的实体类，对EO的操作会对数据库产生影响。
DTO（Data Transfer Object，数据传输对象），用于在各个层之间传递数据的普通类，DTO有哪些属性取决于其他层要什么数据。DTO一般是扁平类，也就是没有什么关联属性，都是普通类型的属性，一些复杂项目中，数据访问层和业务逻辑层直接传递用一个DTO类，DTO类类似与三层架构中的Model。
EO 相当于DataTable，不能传输到DAL之外； DTO就是三层Model，在各个层中间传输数据用的
VIewModel（视图模型），用来组合来自其他层的数据显示到UI层，简单的数据可能可以直接把DTO交给界面显示，一些复杂的数据可以要重新转换为VIewModel对象。
二、多层架构
搭建一个ASP.NET MVC三层架构项目：DAL、BLL、DTO、UI（asp.net.mvc）。UI、DAL、BLL 都引用DTO；BLL引用DAL；EF中所有的代码都定义到DAL， BLL中只访问DAL、BLL中不要引用DAL中EF的类，不要在BLL中执行Include操作，所有数据准备工作都在DAL中完成
三、架构退化
UI+BLL+DAL => UI+Service
合适的架构：能够满足当前项目的要求，并且适度的考虑以后的项目的发展，不要想的太远，不要“过度架构”，让新手能够快速入手
UI项目虽然不直接访问EF中的类，但是仍然需要在UI项目的App.config（Web.config）中对EF做配置，也要在项目中通过Nuget安装EF，并且把连接字符串配置在UI的web.config中