У меня есть приложение MVC 3, и я создал универсальный объект-обертку, который имеет некоторые свойства навигации и обернутый объект T, значения которого я редактирую / отображаю.
public class NavigationViewModel<T>
{
public T Model { get; set; }
public NavigationHelper NavigationHelper { get; set; }
public NavigationViewModel() { }
public NavigationViewModel(T model, NavigationHelper helper)
{
this.Model = model;
this.NavigationHelper = helper;
}
}
Мой контроллерразрешает этот объект с помощью действия, подобного этому:
public ActionResult Foo(NavigationViewModel<Bar> viewModel)
Код, на мой взгляд, выглядит следующим образом:
@Html.EditorFor(model => model.Model.SomeProperty)
Мой коллега сказал, что этот код плохо читать.У меня уже есть строго типизированное представление, Модель и эта Модель имеют другое свойство, которое называется Модель.Он предложил переименовать свойство Model во ViewModel, и я согласился с его рассуждениями.
Теперь код с переименованными свойствами больше не работает: NavigationViewModel viewModel имеет значение null.Поэтому я изменил сигнатуру метода HttpPost следующим образом, и он снова работает:
[HttpPost]
public ActionResult Foo(NavigationHelper helper, Bar viewModel)
Мне это очень нравится!Я могу напрямую обращаться к моей viewModel в коде, код в представлении имеет смысл, и вспомогательный объект не мешает.Я не видел этого соглашения раньше, и я думаю, что он работал раньше из-за соглашения об именах.Использование свойства Model подсказало, как разрешить объект.Без этого свойства оно не могло бы решить это больше.
Я хотел бы принять это для других типов помощников, которые содержат специфичные для вида свойства, такие как списки выбора или другие свойства, которые я иначе мог бы поместить в свой ViewBag.Ребята, порекомендуете ли вы такой подход или у меня возникнут проблемы позже при использовании этого?