У меня есть приложение MVC 3, и я создал общий объект-оболочку, который имеет некоторые свойства навигации и обернутый объект T, значения которого я редактирую/отображаю.MVC 3 сплит-параметры в действии HttpPost
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 и эта модель имеют другое свойство, называемое Model. Он предложил переименовать свойство Model в ViewModel, и я согласился с его рассуждениями.
Теперь код с переименованными свойствами больше не работает: NavigationViewModel viewModel имеет значение NULL. Поэтому я заменил подпись метода HttpPost следующим образом: он работает снова:
[HttpPost]
public ActionResult Foo(NavigationHelper helper, Bar viewModel)
Мне это очень нравится! Я могу напрямую получить доступ к моей viewModel в коде, код в представлении имеет смысл, и вспомогательный объект не мешает. Я не видел этого соглашения раньше, и я предполагаю, что он работал раньше из-за соглашения об именах. Использование свойства под названием «Модель» намекает на то, как разрешить объект. Без этого имущества он больше не мог его разрешить.
Я хотел бы принять это для других видов помощников, которые содержат специфические для просмотра свойства, такие как списки выбора или другие свойства, которые я мог бы поместить в свой ViewBag. Не могли бы вы, ребята, порекомендовать этот подход или я могу столкнуться с проблемой позже?
Дженерики хорошие, но нередко они приводят к чрезмерной инженерии. Чего вы пытаетесь достичь? Что касается соглашений об именах, я считаю, что ваш коллега прав, но просто называть его моделью обзора решает половину проблемы. Я ожидаю, что смогу определить цель класса, просто посмотрев его имя и свойства. –
Навигационная система просмотра - это средство для тегов по всем видам информации, например, нажатие кнопки, чтобы вызвать обратную передачу, и если я хочу показывать кнопки (мы разрабатываем очень динамичный и странный поток). Я могу повторно использовать эту часть и позволить T, viewmodel, взаимозаменяемы. Вызов его viewmodel может быть не более ясным, но он заставил меня обнаружить, что вы можете использовать/злоупотреблять/обманывать связующее устройство в решении двух объектов вместо оболочки с внутренним объектом. – Vincent
Это звучит как проблема дизайна. Исправьте меня, если я ошибаюсь, но вы говорите, что хотите отслеживать состояние страницы, с которой работает пользователь. Если это так, то веб-формы могут быть лучшим решением для этого. Кроме того, слух «post-backs» с MVC звучит неправильно. Может быть, попробуйте поделиться дополнительной информацией о своем дизайне? В любом случае, это довольно интересно, и было бы неплохо увидеть больше мнений. –