2012-03-26 1 views
3

У меня есть приложение 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. Не могли бы вы, ребята, порекомендовать этот подход или я могу столкнуться с проблемой позже?

+0

Дженерики хорошие, но нередко они приводят к чрезмерной инженерии. Чего вы пытаетесь достичь? Что касается соглашений об именах, я считаю, что ваш коллега прав, но просто называть его моделью обзора решает половину проблемы. Я ожидаю, что смогу определить цель класса, просто посмотрев его имя и свойства. –

+0

Навигационная система просмотра - это средство для тегов по всем видам информации, например, нажатие кнопки, чтобы вызвать обратную передачу, и если я хочу показывать кнопки (мы разрабатываем очень динамичный и странный поток). Я могу повторно использовать эту часть и позволить T, viewmodel, взаимозаменяемы. Вызов его viewmodel может быть не более ясным, но он заставил меня обнаружить, что вы можете использовать/злоупотреблять/обманывать связующее устройство в решении двух объектов вместо оболочки с внутренним объектом. – Vincent

+0

Это звучит как проблема дизайна. Исправьте меня, если я ошибаюсь, но вы говорите, что хотите отслеживать состояние страницы, с которой работает пользователь. Если это так, то веб-формы могут быть лучшим решением для этого. Кроме того, слух «post-backs» с MVC звучит неправильно. Может быть, попробуйте поделиться дополнительной информацией о своем дизайне? В любом случае, это довольно интересно, и было бы неплохо увидеть больше мнений. –

ответ

0

Я думаю, что у меня есть очень простой ответ для вас, просто не дали ему имя параметра действия ViewModel, поэтому изменить:


public ActionResult Foo(NavigationViewModel viewModel) 

public ActionResult Foo(NavigationViewModel model) 

Или любое другое имя параметра, который не вступает в противоречие с ViewModel свойство в вашем классе NavigationViewModel.

 Смежные вопросы

  • Нет связанных вопросов^_^