Советы по работе с временным запросом на изменение в MVC View

Question

Я работаю над приложением, для которого к данной функции поступил временный запрос на изменение. В частности, компания в настоящее время хочет управлять физическим адресом только для определенного клиента и хочет, чтобы мы удалили опцию добавления почтового адреса.

Скорее всего, в будущем эту функцию, вероятно, потребуется повторно внедрить, поэтому мне интересно, какой сейчас лучший способ справиться с удалением. Наличие дополнительных свойств в ViewModel не обязательно является проблемой, но это грязно. И еще больше проблем, когда речь идет о самом View. Нам нужно удалить элементы пользовательского интерфейса, но мы должны упростить его возврат в будущем.

Итак ... я закомментирую ненужные биты кода? Это самый простой подход, но он грязный.

Создать ли новый View и ViewModel? Если это так, где находится подходящее место для хранения оригинала для хранения? Наше приложение находится под контролем исходного кода (SVN), поэтому теоретически мы могли бы вернуться к этой ревизии, но, похоже, излишне для такого небольшого изменения.

Кто-нибудь еще сталкивался с подобной ситуацией? Любая рекомендация о том, как лучше всего справиться с этим?

Answer 1

Итак ... я закомментирую ненужные биты кода?

Нет, это было бы очень грязно.Это то, для чего предназначено управление версиями.

Создать новый View и ViewModel?

Да, заменить оригинал.

Если это так, где находится подходящее место для хранения оригинала для хранения?

Контроль версий.

Наше приложение находится под контролем исходного кода (SVN), поэтомуМы теоретически могли бы вернуться к этой ревизии, но, кажется, это излишество для такого небольшого изменения.

избыточное количество?Нет. Это то, что лучше всего делают VCS => они хранят историю изменений.Также вы можете подумать о создании ярлыка, чтобы вы могли легко вернуться позже.

Answer 2

Какой вид двигателя? На самом деле, это может иметь или не иметь значения.

С точки зрения "мне может понадобиться это в будущем", я бы рассмотрел перемещение битов пользовательского интерфейса, которые сейчас уходят и могут снова появиться в пользовательском элементе управления MVC. Это менее «грязно», чем комментирование кода повсюду. Затем вы можете исключить его сейчас.

Что касается ViewModel? Есть несколько возможностей. Короткий полюс, безусловно, добавляет биты в ViewModel, даже если он не используется, но это означает, что вы раскручиваете данные, которые не используются, без четких сроков, когда они будут использоваться. Но вы всегда можете создать производный класс, когда вам понадобится дополнительная информация, и пользовательский элемент управления приведёт модель представления к производному классу (ко-дисперсия и контр-дисперсия - ваши друзья), когда вы начнете использовать его, делая изменения кода довольно незначительными. когда бизнес "приходит в себя".