DRY 与 MVC 和视图模型的安全性和可维护性
我喜欢努力做到 DRY，但显然这并不总是可能的。然而，我不得不对 MVC 中似乎很常见的一个概念摸不着头脑，即“视图模型”。
出于安全性、可维护性和测试考虑，视图模型旨在仅向视图传递最少量的信息。我明白了。这是有道理的。
然而，从 DRY 的角度来看，视图模型只是复制您已有的数据。视图模型可能是临时的，并且仅用作 DTO，但您基本上维护同一模型的两个不同版本，这似乎违反了 DRY 原则。
视图模型是否违反了 DRY？它们是必要的恶吗？他们做的好事多于坏事吗？
I like to strive for DRY, and obviously it's not always possible. However, I have to scratch my head over a concept that seems pretty common in MVC, that of the "View Model".
The View Model is designed to only pass the minimum amount of information to the view, for both security, maintainability, and testing concerns. I get that. It makes sense.
However, from a DRY perspective, a View Model is simply duplicating data you already have. The View Model may be temporary, and used only as a DTO, but you're basically maintaing two different versions of the same model which seems to violate the DRY principal.
Do View Models violate DRY? Are they a necessary evil? Do they do more good than bad?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这一点已经被一再提起。它不仅是一个相当大的骗局，而且答案是主观的和有争议的。 ViewModel 是对 DDD 和持久性无知概念的回应。
说不使用 ViewModel 不好意味着忽略了 Django 和 Rails 以及大多数 PHP ORM/MVC 框架根本不关心这些概念。您是否希望有人告诉您所有其他语言和框架“都做错了”？
您是否想要使用 ViewModel 100% 取决于您想要的架构风格以及应用程序的目标是什么。
这就像问在 WebForm 应用程序中拖放 GridView 是否合适？取决于很多事情。
您对 DRY 也存在误解。 WCF 服务中的代理类是否违反 DRY？ ViewModel 包含逻辑吗？ DRY 的主要目标是不存在具有有意义目的的重复逻辑。几个共享对象形状的 DTO 是否违反了这一点？
有界上下文的 DDD 原则也值得一读。如果 ShoppingCart 对象需要在仓库和电子商务网站设置中以不同的方式运行，这是否意味着您要共享类型？当唯一的共享功能是合计价格（价格 + 税费 + 运费）时会发生什么？您是否为此创建了一个基类，从而增加了耦合？对于像 GetTotal() 这样的简单方法，要实现 100% DRY，需要在时间/成本/维护方面进行哪些权衡。在有意义的情况下违反 DRY 是否实际上会降低维护代码库的复杂性和总体成本？
我很抱歉回答了这么多问题，但希望现在您能看到您所问问题的细微差别和复杂性。 ;)
This has been brought up time and time again. Not only is it a pretty substantial dupe but the answer is subjective and argumentative. ViewModels are a response to DDD and the concept of persistence ignorance.
To say not using ViewModels is bad means ignoring that Django and Rails and most PHP ORM/MVC frameworks don't care at all about those concepts. Do you want somebody to tell you all those other languages and frameworks are "doing it wrong?".
Whether or not you want to use ViewModels is 100% dependent on what architecture styles you are going for and what the goals of the application are.
This is like asking is dragging and dropping GridViews in a WebForm app appropriate? Depends on a lot of things.
There is also a misconception about DRY that you have here. Do Proxy classes from a WCF service violate DRY? Does the ViewModel contain logic? The primary goal of DRY is to not have duplicated logic with a meaningful purpose. Do a couple of DTOs that share object shapres violate that?
The DDD principal of bounded contexts would make for a good read too. If a ShoppingCart object needs to function differently in a warehouse vs ecommerce website setting does that mean you to share the types? What happens when the only shared functionality is totaling a price ( price + tax + shipping )? Do you create a base class just for that therefore increasing coupling? What are the tradeoffs in time/cost/maintenance for being 100% DRY for a simple method like GetTotal(). Does violating DRY when it makes sense actually decreasing the complexity and overall cost of maintaining your codebase?
I'm sorry for answering with so many questions but hopefully now you can see the nuances and intricacies of the question you asked. ;)
人们还可能注意到，不使用视图模型将违反单一职责原则——您的实体不应该受到 UI 问题的污染。
我还认为视图模型的真正价值并不一定会在应用程序的 1.0 版本中变得明显。在使用 2.0 版本时，当您完全重新思考后端的工作方式时，您会感谢自己，但不必将这些更改带到视图层。
One could also note that not using view models would be a violation of the single responsibility principle -- your entity should not be polluted with UI concerns.
I also think the real value of view models doesn't necessarily become apparent in version 1.0 of your application. You will thank yourself when working on version 2.0 when you completely re-think how your back-end works but you don't have to carry those changes out to the view layer.