Советы по работе с временным запросом на изменение в MVC View
Я работаю над приложением, для которого к данной функции поступил временный запрос на изменение. В частности, компания в настоящее время хочет управлять физическим адресом только для определенного клиента и хочет, чтобы мы удалили опцию добавления почтового адреса.
Скорее всего, в будущем эту функцию необходимо будет повторно внедрить, поэтому мне интересно, каким будет лучший способ обработки удаления на данный момент. Наличие дополнительных свойств в ViewModel не обязательно является проблемой, но это грязно. И еще больше проблем, когда речь идет о самом View. Нам нужно удалить элементы пользовательского интерфейса, но мы должны упростить его возврат в будущем.
Итак... я закомментирую ненужные биты кода? Это самый простой подход, но он грязный.
Создать новый View и ViewModel? Если это так, где находится подходящее место для хранения оригинала для хранения? Наше приложение находится под контролем исходного кода (SVN), поэтому теоретически мы могли бы вернуться к этой ревизии, но, похоже, излишне для такого небольшого изменения.
Кто-нибудь еще сталкивался с подобной ситуацией? Любая рекомендация о том, как лучше всего справиться с этим?
2 ответа
Итак... я закомментирую ненужные биты кода?
Нет, это было бы очень грязно. Вот для чего предназначен контроль версий.
Создать новый View и ViewModel?
Да, заменить оригинал.
Если это так, где находится подходящее место для хранения оригинала для хранения?
Контроль версий.
Наше приложение находится под контролем исходного кода (SVN), поэтому теоретически мы могли бы вернуться к этой ревизии, но, похоже, излишне для такого небольшого изменения.
Overkill? Нет. Это то, что лучше всего делают VCS => они хранят историю изменений. Также вы можете подумать о создании ярлыка, чтобы вы могли легко вернуться позже.
Какой вид двигателя? На самом деле, это может иметь или не иметь значение.
С точки зрения "мне может понадобиться это в будущем", я бы рассмотрел перемещение битов пользовательского интерфейса, которые сейчас уходят и могут снова появиться в пользовательском элементе управления MVC. Это менее "грязно", чем комментирование кода повсюду. Вы можете исключить это сейчас.
Что касается ViewModel? Есть несколько возможностей. Короткий полюс, безусловно, добавляет биты в ViewModel, даже если он не используется, но это означает, что вы раскручиваете данные, которые не используются, без четких сроков, когда они будут использоваться. Но вы всегда можете создать производный класс, когда вам нужна дополнительная информация, и когда пользовательский элемент управления преобразует модель представления в производный класс (когда вы начинаете использовать его, вы изменяете код и вносите в него небольшие изменения) когда бизнес "приходит в себя".