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

Question

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

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

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

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

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

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

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

Я буду очень внимательно читать дискуссию, которую надеюсь зажечь. Большое спасибо заранее.

Answer 1

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

У меня есть образец asp.net-mvc application , где я демонстрирую лучшие практики выполнения этого в mvc, вы можете увидеть это в загрузке 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);

Answer 2

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

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

Таким образом, использование определенной модели позволяет вам гарантировать, что редактировать можно только те поля, которые вы хотите отредактировать.

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 from, obj to) - это новая функция в последней версии MvcFutures . Также обязательно ознакомьтесь с Extensible Model Binder в MVC Futures 2.

Answer 4

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

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

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

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

Извините, мой текст очень запутанный, но я и сам сейчас очень запутался, плюс мне пора бежать. Как и С.Т., комментировать тоже не смог.