我喜欢争取 DRY，显然这并不总是可能的。但是，我不得不为一个在 MVC 中似乎很常见的概念，即“ View 模型”的概念而挠头。
出于安全性、可维护性和测试方面的考虑， View 模型旨在仅将最少量的信息传递给 View 。我明白了。这说得通。
但是，从 DRY 的角度来看， View 模型只是复制您已有的数据。 View 模型可能是临时的，仅用作 DTO，但您基本上维护的是同一模型的两个不同版本，这似乎违反了 DRY 原则。
View 模型是否违反 DRY？它们是必要的邪恶吗？他们做的比坏的多吗？
最佳答案
这已经一次又一次地被提起。这不仅是一个相当大的骗局，而且答案是主观的和有争议的。 ViewModels 是对 DDD 和持久性无知概念的回应。
说不使用 ViewModels 是不好的意思是忽略 Django 和 Rails 以及大多数 PHP ORM/MVC 框架根本不关心这些概念。您是否希望有人告诉您所有其他语言和框架都“做错了？”。
您是否要使用 ViewModels 100% 取决于您要采用的架构风格以及应用程序的目标是什么。
这就像问在 WebForm 应用程序中拖放 GridViews 是否合适？取决于很多事情。
您在这里也对 DRY 存在误解。来自 WCF 服务的代理类是否违反 DRY？ ViewModel 是否包含逻辑？ DRY 的主要目标是不具有具有有意义目的的重复逻辑。共享对象形状的几个 DTO 是否违反了这一点？
有界上下文的 DDD 原则也可以很好地阅读。如果 ShoppingCart 对象需要在仓库和电子商务网站设置中以不同的方式运行，这是否意味着您要共享类型？当唯一的共享功能是总计价格(价格 + 税费 + 运费)时会发生什么？您是否为此创建了一个基类，从而增加了耦合？对于像 GetTotal() 这样的简单方法来说，100% DRY 在时间/成本/维护方面的权衡是什么？在有意义的情况下违反 DRY 是否会降低维护代码库的复杂性和总体成本？
我很抱歉回答了这么多问题，但希望现在您可以看到您提出的问题的细微差别和复杂性。 ;)
关于asp.net-mvc - DRY 与 MVC 和 View 模型的安全性和可维护性，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4564477/