在 MVC 视图中处理临时更改请求的提示
我正在开发一个应用程序，该应用程序的某个特定功能收到了临时更改请求。具体来说，该企业目前只想管理给定客户的实际地址，并希望我们删除添加邮寄地址的选项。
将来很可能需要重新引入此功能，因此，我想知道目前处理删除的最佳方法是什么。在 ViewModel 上拥有额外的属性不一定是个问题，但它很混乱。当涉及到视图本身时，问题就更大了。我们需要删除 UI 元素，但是，我们需要方便将来将其恢复。
那么...我是否注释掉不需要的代码位？这是最简单的方法，但是很混乱。
我要创建一个新的 View 和 ViewModel 吗？如果是，那么将原件存放在哪里合适？我们的应用程序处于源代码控制 (SVN) 之下，因此，理论上我们可以回到此修订版，但是，对于如此小的更改来说，这似乎有点矫枉过正。
还有其他人遇到过类似的情况吗？关于如何最好地处理这个问题有什么建议吗？
I am working on an application, for which a temporary change request has come in to a given feature. Specifically, the business currently only wants to manage a Physical address for a given customer, and wants us to remove the option to add a mailing address.
This feature will most likely need to be re-introduced in the future, so, I am wondering what the best way to handle the removal would be for now. Having additional properties on the ViewModel is not necessarily a problem, but, it's messy. And there is even more of a problem when it comes to the View itself. We need to remove the UI elements, but, we need to make it easy to bring it back in the future.
So...do I comment out the unneeded code bits? This is the simplest approach, but, it's messy.
Do I create a new View and ViewModel? If so, where is the appropriate place to store the original for safe-keeping? Our application is under source control (SVN), so, we could theoretically come back to this revision, but, it seems like overkill for such a small change.
Has anyone else run into a similar situation? Any recommendation on how to best handle this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不，那会非常混乱。这就是版本控制的目的。
是的，换掉原来的。
版本控制。
矫枉过正？不，这就是 VCS 最擅长的 =>他们保留修订历史记录。您也可以考虑创建一个标签，以便稍后可以轻松返回。
No, that would be very messy. That's what version control is intended to do.
Yes, replace the original.
Version control.
overkill? No. That's what VCS do best => they keep revision history. Also you might consider creating a label so that you can easily come back later.
什么视图引擎？事实上，这可能重要也可能不重要。
从“我以后可能需要这个”的角度来看，我会考虑移动暂时消失并可能重新出现在 MVC 用户控件中的 UI 位。与到处注释代码相比，它没有那么“混乱”。然后您可以暂时排除它。
至于视图模型？有几种可能性。短杆肯定会向 ViewModel 添加位，即使没有使用，但这意味着您正在旋转未使用的数据，并且没有明确的使用时间范围。但是，当您需要额外信息时，您始终可以创建派生类，并在开始使用它时让用户控件将视图模型强制转换为派生类（协变和逆变是您的朋友），从而使代码更改相当小当企业“清醒过来”时。
What view engine? Actually, that may or may not matter.
From a standpoint of "I may need this going forward", I would consider moving the UI bits that are going away for now and may reappear in an MVC user control. It is less "messy" than commenting out code all over the place. You can then exclude it for now.
As for the ViewModel? There are a couple of possibilities. The short pole is certainly adding the bits to the ViewModel, even if not used, but that means you are spinning up data that is not in use with no clear timeframe for when it will be used. But you can always create a derived class when you need the extra information and have the user control cast the view model to the derived class (co-variance and contra-variance are your friends) when you start using it, making code changes rather minor when the business "comes to its senses".