我正在使用 Model First 阅读 MVC3 和 Linq to Entities 的本教程。
http://msdn.microsoft.com/en-us/data/gg685489.aspx
文章中的一句话说
我们的控制器将使用 BlogDataEntities 为我们检索数据。在更高级的应用程序中,您应该进一步分离逻辑并且不会直接从控制器使用 BlogDataEntities。
MVC 应用程序中实体和控制器之间的其他层的一般结构是什么?什么目的?
我正在使用 Model First 阅读 MVC3 和 Linq to Entities 的本教程。
http://msdn.microsoft.com/en-us/data/gg685489.aspx
文章中的一句话说
我们的控制器将使用 BlogDataEntities 为我们检索数据。在更高级的应用程序中,您应该进一步分离逻辑并且不会直接从控制器使用 BlogDataEntities。
MVC 应用程序中实体和控制器之间的其他层的一般结构是什么?什么目的?
我通常有一个混蛋 ViewModel(参见http://en.wikipedia.org/wiki/Model_View_ViewModel),其中包含业务逻辑,可以从 EF 获取/保存,并且是视图绑定的内容。控制器做的不多,只是实例化了视图模型,并根据控制器的动作,在视图模型中调用一个方法。
有些人可能会进一步打破它,并拥有一个完整的 ViewModel,其中没有逻辑,只有数据。具有所有逻辑的业务层,并且能够将数据从 EF 移动到 ViewModel,反之亦然。
在文章中“BlogDataEntities”不是某些特定实体类的名称(顾名思义),而是 DbContext 的名称。
我想这意味着您将尝试通过不实例化 DbContext 而是通过使用像这样的存储库实现来隐藏您使用 EF