DRY 与 MVC 和视图模型的安全性和可维护性答案

【问题标题】：DRY vs Security and Maintainability with MVC and View ModelsDRY 与 MVC 和视图模型的安全性和可维护性
【发布时间】：2010-12-30 16:48:29
【问题描述】：

我喜欢为 DRY 努力，显然这并不总是可行的。然而，我不得不对一个在 MVC 中似乎很常见的概念“视图模型”感到头疼。

出于安全性、可维护性和测试方面的考虑，视图模型旨在仅将最少量的信息传递给视图。我明白了。这说得通。

但是，从 DRY 的角度来看，视图模型只是复制您已有的数据。 View Model 可能是临时的，仅用作 DTO，但您基本上维护的是同一模型的两个不同版本，这似乎违反了 DRY 原则。

视图模型是否违反 DRY？它们是必要的邪恶吗？他们做的好事多于坏事吗？

【问题讨论】：

标签： asp.net-mvc viewmodel dry

【解决方案1】：

这已经被一次又一次地提出来了。这不仅是一个相当大的欺骗，而且答案是主观的和有争议的。 ViewModel 是对 DDD 和持久性无知概念的回应。

说不使用 ViewModel 是不好的，意味着忽略 Django 和 Rails 以及大多数 PHP ORM/MVC 框架根本不关心这些概念。您是否希望有人告诉您所有其他语言和框架都“做错了”。

您是否要使用 ViewModel 100% 取决于您所采用的架构风格以及应用程序的目标是什么。

这就像问在 WebForm 应用程序中拖放 GridViews 是否合适？取决于很多事情。

您对 DRY 也有误解。 WCF 服务中的代理类是否违反 DRY？ ViewModel 是否包含逻辑？ DRY 的主要目标是不具有有意义的重复逻辑。几个共享对象形状的 DTO 是否违反了这一点？

有界上下文的 DDD 原则也有助于阅读。如果 ShoppingCart 对象需要在仓库与电子商务网站设置中发挥不同的作用，这是否意味着您要共享类型？当唯一的共享功能是合计价格（价格+税+运费）时会发生什么？您是否为此创建了一个基类，从而增加了耦合？对于像 GetTotal() 这样的简单方法来说，100% DRY 在时间/成本/维护方面的权衡是什么？在有意义的情况下违反 DRY 是否会降低维护代码库的复杂性和总体成本？

很抱歉回答了这么多问题，但希望现在您可以看到您提出的问题的细微差别和复杂性。 ;)

【讨论】：

我在发布此之前进行了搜索，但找不到任何类似的问题。有一些与silverlight 相关（但视图模型在那里完全不同），还有一些关于rails 的东西（可能有些相关，但不一样）。我之所以这么问，是因为 DRY 是 MVC 建模的 rails 方法的主要目标之一。似乎 MVC 有时对其重视的原则有些精神分裂。
也许您应该实际阅读结果。它们都不适用。
stackoverflow.com/questions/3970763/…

【解决方案2】：

人们还可以注意到，不使用视图模型将违反单一职责原则——您的实体不应受到 UI 问题的污染。

我还认为，视图模型的真正价值并不一定会在应用程序的 1.0 版中体现出来。在使用 2.0 版本时，您会感谢自己，因为您完全重新考虑后端的工作方式，但您不必将这些更改带到视图层。

【讨论】：

我真的不明白它会如何违反 SRP，因为 SRP 与其说是模型问题，不如说是控制器问题。
SRP 对于任何地方的每个应用程序都是一个问题。这可以说是最重要的 OOP 原则。