我在MVC中使用ViewModels。我发现它们非常难以理解,并想知道我是否做错了什么。 (为了讨论起见,让我们离开Automapper。)我使用viewmodels将数据发送到客户端以及接收表单提交。一些属性被发送到浏览器仅供显示,其他属性被发送和放大。检索(例如,字段)。
我通常必须实现以下内容才能使viewmodel工作:
1)创建一个视图模型类
2)创建一个通用函数来初始化视图模型&从我的实体复制属性&其他来源
3)编写更多代码,以便在提交时将一些值从viewmodel写回实体(或其他目的地)
4)如果存在服务器端验证错误,我需要编写更多代码(特别是凌乱)来重新填充viewmodel的只读部分(包含在提交中),同时注意不要覆盖用户提交的数据。
对于一个简单的属性(例如" myViewModel.FirstName"),这需要在不少于4个位置写入代码。那不包括域和视图中的内容。这种模式对我来说似乎很脆弱 - 例如,它很容易破解代码。忘记在所有地点实施变更。绝对不是DRY。
我是否忽略了这一点,或者使用ViewModel进行的所有模式都有这种克制?
答案 0 :(得分:2)
我不确定你发现了什么? MVC是关于关注点的分离。保持业务逻辑,数据层和GUI代码分离。这本身使您的代码更易于管理,更易于测试,而且调试的混乱也更少。
让我们看看你的四点。
第1点。首先,为您的视图模型创建POCO真的是一个很大的问题吗?我不这样说,因为你可以在大约3行代码中完成这个,给出你的例子。如果你的模型需要改变,那么在你自己的视图模型类中,而不是直接在你可能已经使用它的每个控制器中的每个动作方法中的代码中,它会不会更有益吗?
积分2 + 3。在这里,您谈到从数据层到逻辑层再次查看和返回。这是MVC的重点。仅仅因为你必须编写三个类(模型,服务,存储库)来处理这个事务并不会使这个繁琐,它使它变得干净。试想一下,如果你把所有这些都放在控制器动作方法上。你会如何处理重复使用?您如何防止在其他操作或控制器中重复代码?事情会变得非常困难。
第4点。我并不认为这是一个有效的参数,因为您只需传回用户提交的模型,无需更新或编辑它。通过使用数据注释和ModelState进行验证,创建一个干净且可测试的代码单元非常简单。所以我想这不是你使用ViewModel的事实,而是可能更多地与你的实现有关。