Рекомендации по обновлению модели модели и модели с подмножеством полей

Question

Выбрав MVC для разработки нашего нового сайта, я нахожусь в разгаре «лучших практик», разрабатываемых вокруг меня в явном реальном времени. Две недели назад NerdDinner был моим проводником, но с разработкой MVC 2, даже он устарел. Это захватывающий опыт, и я чувствую себя привилегированным в тесном контакте с умными программистами ежедневно.

Прямо сейчас я наткнулся на проблему, на которую я, похоже, не могу получить прямой ответ - от всех блогов в любом случае - и я хотел бы получить некоторое представление от сообщества. Речь идет об редактировании (читайте: «Изменить действие»). Основная часть материала, учебники и блоги, посвящена созданию и просмотру модели. Поэтому, хотя в этом вопросе не может быть и речи, я надеюсь, что вы продолжите обсуждение, внося свой вклад в мое решение о пути развития, который я должен предпринять.

Моя модель представляет пользователя с несколькими полями, такими как имя, адрес и адрес электронной почты. Все имена, по сути, в поле для каждого имени, фамилии и имени. В представлении «Сведения» отображаются все эти поля, но вы можете изменять только один набор полей за раз, например, ваши имена. Пользователь расширяет форму, в то время как другие поля все еще видны сверху и снизу. Таким образом, форма, отправленная назад, содержит подмножество полей, представляющих модель.

Несмотря на то, что это привлекательно для нас и наши макеты, по разным причинам, его избегают серьезные MVC-разработчики. Я читал о некоторых шаблонах и лучших практиках, и кажется, что это не является ключом к парадигме viewmodel == view. Или я ошибаюсь?

В любом случае, NerdDinner диктует использование FormCollection och UpdateModel. Все нулевые поля счастливо игнорируются. С тех пор сообщество MVC отказалось от такого подхода до такой степени, что bug в MVC 2 не был обнаружен. UpdateModel не работает без полной модели в вашем формате.

view model pattern получать большую похвалу, кажется, Dedicated вид модели, которая содержит пользовательские модели вид сущности и является единственным, что мой дизайн вопрос может быть совместим с. Это влечет за собой утомительное количество картографирования, хотя и облегчается использованием AutoMapper и ideas Джимми Богарда, что может быть или не быть целесообразным. Он также предлагает соотношение 1: 1 между моделью просмотра и представления.

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

Я очень внимательно прочитаю дискуссию, которую я надеюсь искры. Спасибо заранее.

Answer 1

У меня такая же проблема, но я бы не смог ее сформулировать так хорошо.

В моем случае было бы тонны ViewModels, потому что разные пользователи будут видеть разные формы на основе набора ролей. Я думаю, что соотношение 1: 1 между ViewModel и View очень расплывчато. Что делать, если я пишу uber-View, который просто использует EditorForModel и не намного больше? Теперь у меня есть один, хотя и сильно вырожденный, взгляд на все, поэтому у меня также есть только один ViewModel?

Моя идея состояла в том, чтобы написать EditorForModel, который работает не только на основе отражения (то есть информации, известной во время компиляции), но и на (определенных по определенному домену) правилах выполнения, например, определяемых ролью текущего пользователя, текущей времени и т. д.Следовательно, нужно также написать настраиваемый ModelBinder с проверкой, а также настраиваемое сопоставление от Model to ViewModel. Тем не менее, это мешает мне писать глупый и, следовательно, код, подверженный ошибкам.

Поскольку моя модель (или DomainModel) содержит много логики, я не хочу, чтобы она была модифицирована с помощью ModelBinding. Более того, поскольку невозможно узнать, какие поля будут присутствовать во время компиляции, обеспечить подходящую ViewModel невозможно. Тем не менее, «полный», т. Е. Максимальный ViewModel, известен. Картирование из ViewModel в модель снова включает пользовательский код, но до тех пор, пока правила могут быть формализованы, это должно сработать.

Извините, мой текст очень запутан, но я очень смущен прямо сейчас, плюс я должен бежать. Подобно C.T., также не мог комментировать.

Answer 2

Недавно было опубликовано несколько сообщений о проверке ваших моделей, в результате чего этот пост от Брэда Уилсона «Input Validation vs. Model Validation in ASP.NET MVC».

Первоначальная проблема заключалась в том, как ASP.NET MVC обработала проверку опубликованной модели, и если бы были элементы вашей модели, которые вы не хотели редактировать и не предоставляли поля для представления, но ваш контроллеры работали со всей моделью, возможно, кто-то может создать POST для вашего контроллера с дополнительными полями.

Поэтому использование View Spec Model позволяет вам отредактировать только те поля, которые вы хотите отредактировать.

Answer 3

Проверьте это. Это путь с ASP.NET MVC 2.

 public void Update(MyModel model) 
     { 
      var myModelObject = MyRepository.GetInstance(model.Id); 
      if(myModelObject != null) 
      { 
       ModelCopier.CopyModel(model, myModelObject); 
      } 
      MyRepository.Save(myModelObject); 
     } 

ModelCopier.CopyModel (OBJ из, OBJ в) новая функция в последнем MvcFutures. Также не забудьте проверить Extensible Model Binder в MVC Futures 2.

Answer 4

Я делаю это так (отображение выполняется автоматически внутри MODELBUILDER с ValueInjecter):

У меня есть образец жереха .net-приложение MVC, где я показываю лучшие практики делать это в MVC, вы можете увидеть его в download of the valueinjecter

public ActionResult Edit(long id) 
{ 
     return View(modelBuilder.BuildModel(personService.Get(id))); 
} 

[HttpPost] 
public ActionResult Edit(PersonViewModel model) 
{ 
    if (!ModelState.IsValid) 
     return View(modelBuilder.RebuildModel(model));  
     personService.Save(modelBuilder.BuildEntity(model)); 
     return RedirectToAction("Index"); 
} 

быстрый демо ValueInjecter:

//build viewmodel 
    personViewModel.InjectFrom(person) 
        .InjectFrom<CountryToLookup>(person); 

//build entity 
    person.InjectFrom(personViewModel) 
      .InjectFrom<LookupToCountry>(personViewModel);