使用MVC和View模型实现DRY与安全性和可维护性

Question

我喜欢为DRY而努力，显然并非总是可行。但是，我不得不凌驾于一个在MVC中看起来很常见的概念，即“视图模型”。

视图模型旨在仅将最少量的信息传递给视图，以实现安全性，可维护性和测试问题。我明白了。这说得通。

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

视图模型是否违反DRY？他们是必要的邪恶吗？他们做得多好而不是坏吗？

Answer 1

这已经一次又一次地提出来了。它不仅是一个非常重要的骗局，而且答案是主观的和争论性的。 ViewModels是对DDD的响应和持久性无知的概念。

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

您是否要使用ViewModel 100％取决于您要使用的体系结构样式以及应用程序的目标。

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

你对此有一个关于DRY的误解。来自WCF服务的代理类是否违反DRY？ ViewModel是否包含逻辑？ DRY的主要目标是不具有有意义目的的重复逻辑。分享对象shapres的几个DTO是否违反了这个？

有限上下文的DDD原则也可以很好地阅读。如果ShoppingCart对象需要在仓库中以不同的方式运行，那么电子商务网站设置是否意味着您要共享类型？当唯一的共享功能是总价（价格+税+运费）时会发生什么？您是否仅为此创建基类，从而增加耦合？对于像GetTotal（）这样的简单方法，100％DRY的时间/成本/维护的权衡是什么。在有意义的情况下是否违反DRY实际上会降低维护代码库的复杂性和总体成本？

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

Answer 2

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

我还认为视图模型的真正价值在应用程序的1.0版本中并不一定显而易见。当你完全重新思考你的后端如何工作但你不必将这些更改带到视图层时，你会感谢自己在使用2.0版时。