首先,我将 EF 用于Dal层(与 MVC 分离的项目,相同的解决方案)。从 EF 的 EDMX 文件生成的模型是模型层的实际模型?如果是这样,我如何访问这些模型以在 MVC 的视图层中工作?我认为直接从视图访问数据层以使用这些模型是错误的,如果我用“我的模型”制作模型层并将 Dal 的模型转换为我的模型......它将是重复的代码。
可能我弄错了,但大多数是例如。采用代码优先方法,我无法弄清楚这一点。
首先,我将 EF 用于Dal层(与 MVC 分离的项目,相同的解决方案)。从 EF 的 EDMX 文件生成的模型是模型层的实际模型?如果是这样,我如何访问这些模型以在 MVC 的视图层中工作?我认为直接从视图访问数据层以使用这些模型是错误的,如果我用“我的模型”制作模型层并将 Dal 的模型转换为我的模型......它将是重复的代码。
可能我弄错了,但大多数是例如。采用代码优先方法,我无法弄清楚这一点。
您不直接从表示层访问访问 DAL 中的模型的想法是正确的。
为了避免在将 DAL 对象转换为视图使用的模型时重复代码,您可以使用AutoMapper之类的东西,它应该在这种情况下为您完成繁重的工作。
我认为直接从视图访问数据层以使用这些模型是错误的......
没错,合适的方法是使用View Model
当您有数十个不同的值要传递给视图时,允许您快速添加新条目或重命名现有条目的相同灵活性将成为您最大的敌人。您只能自己跟踪项目名称和值;您无法从 Microsoft IntelliSense 和编译器获得帮助。 处理软件复杂性的唯一行之有效的方法是通过适当的设计。因此,为每个视图定义一个对象模型有助于您跟踪该视图真正需要什么。我建议您为添加到应用程序的每个视图定义一个视图模型类。
-- Dino Esposito 的“编程 Microsoft ASP.NET MVC”
ViewModel 提供了您的视图创建自身所需的所有信息。要从 ViewModel 和业务实体传输数据,您可以使用AutoMapper。
不要担心重复,这是两个不同的概念,应该彼此分开;它使您的应用程序易于维护。
I may be mistaking but to me, using generation from EDMX provides you with the DbContext which could be considered as the DAL and entities which could be considered as the Model.
So you might directly manipulate entity instances as your business object. Manipulation of the base through the DbContext should appear in the BLL layer. Additionally, you might implement DTOs where needed.
This, of course, assumes you want to use entity framework code generation. Other options like using POCOs might be more relevant considering your overall architecture.
我在本地项目中使用视图模型,在另一个项目中使用模型。然后在我的视图模型的页面上放置对我将要使用的模型的引用。然后在我的页面上引用视图模型。让我知道这听起来像是您想做的事情,我可以在一些代码中进行编辑。