0

У меня есть проект Mvc4 SPA. Я работаю над тем, где мне нужно иметь несколько видов, вложенных друг в друга. Модели просмотра и просмотра связаны с использованием Durandal.Вложение нескольких просмотров ViewModels в Mvc4 и нокаут

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

Пример ранее использовался в Mvc3 =

Public class ParentsController 
{ 
public ActionResult Parent(int id) 
{ 
    Parent parent = Db.Parents.Find(id); 
    ViewBag.ParentId = parent.Id; 
    return View(parent) 
} 

public PartialViewResult Child(int id) 
{ 
    Child childs = Db.Childs.Where(w => w.ParentId = id); 
    return PartialView("ChildPartial", childs.ToList()); 
} 

public PartialViewResult GrandChild(int id) 
{ 
    GrandChild grandChilds = Db.GrandChilds.Where(w => w.ChildId = id); 
    return PartialView("GrandChildPartial", grandChilds.ToList()); 
} 
} 

и рассматривает что-то вроде

Parent.cshtml 
@{ 
    ViewBag.Title = "Parent"; 
} 
@Html.DisplayFor(Model.ParentName) 
@{Html.RenderAction("ChildPartial", new { id = ViewBag.ParentId});} 


ChildPartial.cshtml 
@{ 
    ViewBag.Title = "Children"; 
} 
{ foreach (var child in childs) 
{ 
@{Html.DisplayFor(child.ChildsName)} 
@{Html.RenderAction("GrandChildPartial", new { id = ViewBag.ChildId});} 
}} 


GrandChildPartial.cshtml 
@{ 
    ViewBag.Title = "Grand Children"; 
} 
{ foreach (var grandChild in GrandChilds) 
{ 
@{Html.DisplayFor(grandChild.GrandChildsName)} 
}} 

Опять же, выше краткий пример шаблона я использовал в прошлом, не нужно помогите с этим.

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

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

ответ

3

Немного рано провозглашать наилучшую практику здесь ... особенно, когда фактический рабочий процесс и характеристики производительности вашего приложения неизвестны (возможно, непознаваемы на данном этапе).

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

Мы намерены выпустить новый образец под названием «TempHire», внедренный в «Hot Towel (ette)», в следующем месяце или около того, что может предложить некоторые рекомендации. Вероятно, время не подходит для вас. Но вы можете найти), и я буду суммировать (и упрощенно) особенность этого образца, которые кажутся уместны на ваш вопрос:

  1. мастер VM связан с корневым объектом (в вашем случае, родитель).

  2. Мастер VM получает «datacontext» (подразделение работы [UoW]), которое предназначено для рабочего процесса этого корневого объекта и помечено идентификатором корневого объекта.

  3. «Unit of Work Manager» создает и отслеживает UoWs корневым идентификатором объекта. Если вы попросите UoW для Parent-1, он либо предоставит вам тот, который он отслеживает, либо создаст для вас новый.

  4. Это позволяет дочерним виртуальным машинам легко обмениваться контекстом данных с мастером и друг с другом довольно развязанным способом. Мастер не должен передавать UoW через цепочку вложенных виртуальных машин. Вместо этого каждой виртуальной машинке вводится «Unit of Work Manager» и может запрашивать «Unit of Work Manager» для UoW по идентификатору родителя; он получит UoW, что «все остальные используют».

  5. Теперь любая виртуальная машина может загружать любые данные, которые ей нужны (или извлекать выгоду из данных в кеше UoW), запросив UoW для этих данных. В VM не нужно «думать» о том, является ли это первым или последним, запрашивать данные, независимо от того, находятся ли данные в кеше или нет, были ли данные получены в начале или по мере необходимости. UoW может инкапсулировать эти детали, подвергая простым «запросам» методы для виртуальных машин.

  6. Конечно, UoW должен предлагать методы «обновления», чтобы соответствовать стойкости ..., которая имеет различное определение для каждого типа в каждом приложении.

  7. Мы стремимся к «песочнице» UoW для каждой задачи, которая обычно ориентирована на корневой объект. Поэтому ведущая VM для Parent-1 имеет свой собственный UoW со своим собственным EntityManager, в то время как ведущая VM для Parent-2 имеет свой собственный UoW со своим собственным EntityManager. Таким образом, пользователь может одновременно работать с Parent-1 и Parent-2 (например, создать порядок № 123 при обновлении порядка # 456) и независимо без смешивания изменений.

  8. «Unit of Work Manager» создает UoW со встроенными EntityManager (EMs). Он создает новые EM с вспомогательным сервисом под названием «EntityManagerProvider». «EntityManagerProvider» отвечает за чистку новых EM и заполнение их «глобальными данными», такими как справочные списки (например, States, StatusCodes, Colors и т. Д.).

  9. «EntityManagerProvider» (EMP) хранит внутренне «главный EM» только для чтения с исходным метаданных и каноническими версиями этих статических списков ссылок. Новые EM, которые он создает, обычно являются копиями этого скрытого мастера EM. Таким образом, общая система делает точно один запрос для метаданных и один запрос для этих статических списков ссылок. EMP заботится о распространении этого исходного материала на новые EM, которые он создает.

Сколько вам нужно? Я не знаю.

+0

Уорд благодарит за отличные и очень подробные ответы. Я видел еще одно сообщение, ссылающееся на TempHire с использованием UoW. Заинтересованы в этом, и, честно говоря, я все еще чувствую, какие технологии будут работать, поэтому я обязательно буду следить за этим. Я, вероятно, собираюсь поиграть с обоими методами и посмотреть, что лучше всего подходит. –

2

Мой друг, Стив Шмидт, предлагает альтернативный аспект атаки, который необходимо учитывать: One ViewModel/Multiple Views.

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

Что поделаешь? Только один ViewModel! Это легко сделать, когда Durandal's «ko compose» настраивает привязку Knockout для присоединения нескольких видов к тому же ViewModel. Вы получаете хорошее разделение на уровне макета без необходимости поддержки параллельных виртуальных машин.

Этот подход хорошо работает, когда логика визуального представления, которая обеспечивает модель, проста, но вы хотите посмотреть на эту модель с разных точек зрения (AKA, «поворот вокруг данных»).

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

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

Подумайте об этом как о дополнении к сверхмощной технике с несколькими VM, описанной в моем другом ответе.

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

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