在 asp.net mvc 的 model 文件夹中创建一个模型是否是最佳实践?并使用这些模型与视图进行交互,并通过使用服务层将我的模型“适配”到 EF 模型。
或者您使用其他方法。这种方法的问题在于,大多数情况下(自制)模型是 EF 模型的副本(不符合DRY原则)。
那么有人能解释一下应该使用哪些模型来处理视图,因为这变得非常混乱。模型/视图模型/Entityframework模型....
解决方案:
感谢各位的回答,我现在需要重构一些东西!
在 asp.net mvc 的 model 文件夹中创建一个模型是否是最佳实践?并使用这些模型与视图进行交互,并通过使用服务层将我的模型“适配”到 EF 模型。
或者您使用其他方法。这种方法的问题在于,大多数情况下(自制)模型是 EF 模型的副本(不符合DRY原则)。
那么有人能解释一下应该使用哪些模型来处理视图,因为这变得非常混乱。模型/视图模型/Entityframework模型....
解决方案:
感谢各位的回答,我现在需要重构一些东西!
正确的方法是为ViewModel和持久化(entity)使用不同的类。通常的原因是你经常需要向视图发送一些额外的数据(例如填充下拉列表的数据,禁用某些字段的数据等),使用不同的验证或者仅显示实体的子集。
我不是纯粹主义者。如果我的ViewModel与实体完全相同,我会直接使用实体,但是一旦需要在视图中添加任何其他信息,我就会重构代码。大多数情况下,我从实体开始,最终以ViewModel结束,因为这是逐步开发的结果。
嗯,这没有意义。我曾经为此苦苦挣扎,我认为你需要一个不是表实体的模型,我称之为领域模型。原因是有时候如果你使用linq2sql,那么你必须处理桥接/链接表(这不是真正的实体)和复杂计算,所以你不能在表实体中完成它,对吧?所以我的方法是有ViewModel <-> Model <-> Entity。
对于我来说,我更喜欢删除标准MVC结构中的Models文件夹,并添加ViewModels文件夹,以存储所有视图模型。正如Ladislav所提到的,在最初的迭代中,这些视图模型可能是从域模型中的实体精确复制,但逐步地它们将会增长并且变得非常不同。