我正在处理临时更改请求已进入给定功能的应用程序。具体来说，企业目前只想管理给定客户的物理地址，并希望我们删除添加邮寄地址的选项。在MVC视图中处理临时更改请求的提示
此功能很可能需要在未来重新引入，因此，我想知道现在处理移除的最佳方法是什么。在ViewModel上有附加属性不一定是问题，但是，它很混乱。当涉及到视图本身时，还有更多的问题。我们需要删除用户界面元素，但是，我们需要让它很容易在将来恢复。
那么......我要注释掉不需要的代码位吗？这是最简单的方法，但是很麻烦。
我是否创建一个新的View和ViewModel？如果是这样，保存原件的适当位置在哪里？我们的应用程序是在源代码控制（SVN）下的，所以，理论上我们可以回到这个修订版，但是对于这样一个小小的改变似乎是过度的。
有没有其他人遇到类似的情况？有关如何最好地处理此问题的任何建议？
所以...我要注释掉不需要的代码位吗？
不，这将是非常混乱。这就是版本控制的目的。
我是否创建一个新的View和ViewModel？
是的，更换原件。
如果是这样，那么保存原件的适当位置在哪里？
版本控制。
我们的应用程序在源代码控制（SVN）下，所以理论上我们可以回到这个修订版本，但是对于这样一个小小的改变似乎有点过分。
矫枉过正？不，那是VCS做得最好的地方=>他们保留修订历史记录。您也可以考虑创建一个标签，以便以后轻松回来。
什么视图引擎？其实，这可能或可能不重要。从“我可能需要向前发展”的观点来看，我会考虑移动现在即将消失的UI位，并可能重新出现在MVC用户控件中。与评论遍布各处的代码相比，它更“杂乱”。您现在可以排除它。
至于ViewModel？有几种可能性。即使没有使用，短杆当然也会将这些位添加到ViewModel中，但这意味着您要旋转未使用的数据，并且没有明确的时间段来使用它。但是当你需要额外的信息时，你总是可以创建一个派生类，并且当你开始使用它时，用户控件将视图模型转换为派生类（协变化和反变化是你的朋友）当企业“意识到”时。
视图引擎是Razor，但是，我同意，这真的不应该。我决定采用类似的方法，从底座派生我自定义的ViewModel，并从可组合的部分视图构建视图，以便在需要时添加此部分，这将是一件简单的事情 – 2011-06-08 23:32:51
你的快速回答证实了我的想法，认为这是做到这一点的最佳方式，但是，我仍然感到非常犹豫。在SVN中，最接近标签的是标签，使用标签用于此目的不适合我们的开发过程（我们标记版本，在我们需要返回分支以进行错误修复的情况下）。 – 2011-06-08 23:08:08