Sugerencias para tratar una request de cambio temporal en una MVC View

Estoy trabajando en una aplicación para la cual ha ingresado una request de cambio temporal a una function determinada. Específicamente, la empresa actualmente solo desea administrar una dirección física para un cliente determinado y quiere que eliminemos la opción de agregar una dirección postal.

Probablemente necesite volver a introducir esta característica en el futuro, por lo tanto, me pregunto cuál sería la mejor forma de manejar la eliminación por el momento. Tener properties adicionales en ViewModel no es necesariamente un problema, pero es complicado. Y aún hay más problemas cuando se trata de la Vista en sí misma. Necesitamos eliminar los elementos de la interfaz de usuario, pero debemos facilitar su recuperación en el futuro.

Entonces … ¿Comente los bits de código innecesarios? Este es el enfoque más simple, pero es desorderado.

¿Creo una nueva vista y model de vista? De ser así, ¿dónde está el lugar apropiado para save el original para su custodia? Nuestra aplicación está bajo control de fuente (SVN), por lo tanto, teóricamente podríamos volver a esta revisión, pero parece demasiado para un cambio tan pequeño.

¿Alguien más se encuentra en una situación similar? ¿Alguna recomendación sobre cómo manejar mejor esto?

Entonces … ¿Comente los bits de código innecesarios?

No, eso sería muy complicado. Eso es lo que el control de versión está destinado a hacer.

¿Creo una nueva vista y model de vista?

Sí, reemplace el original.

De ser así, ¿dónde está el lugar apropiado para save el original para su custodia?

Control de versiones.

Nuestra aplicación está bajo control de fuente (SVN), por lo tanto, teóricamente podríamos volver a esta revisión, pero parece demasiado para un cambio tan pequeño.

¿excesivo? No. Eso es lo que mejor hace VCS => conservan el historial de revisiones. También podría considerar crear una label para que pueda volver fácilmente más tarde.

¿Qué motor de visualización? En realidad, eso puede o no importar.

Desde el punto de vista de "Es posible que necesite esto en el futuro", consideraría mover los bits de la interfaz de usuario que están desapareciendo por el momento y pueden reaparecer en un control de usuario MVC. Es less "desorderado" que comentar código por todos lados. Luego puede excluirlo por ahora.

En cuanto a ViewModel? Hay un par de posibilidades. El polo corto ciertamente está agregando los bits al ViewModel, incluso si no se usa, pero eso significa que está generando datos que no están en uso, sin un calendar claro para el momento en que se utilizarán. Pero siempre puede crear una class derivada cuando necesita la información adicional y hacer que el usuario controle el model de vista a la class derivada (co-varianza y contra varianza son sus amigos) cuando comienza a usarlo, haciendo que los cambios en el código sean menores cuando el negocio "recupera sus sentidos".