Design patterns 嵌套多个视图\Mvc4和敲除中的视图模型

我有一个Mvc4水疗项目，我需要有能力有多个视图嵌套在彼此的工作。视图和视图模型使用Durandal链接

在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从父视图模型中相对轻松地加载子视图和显示子视图，但是当我进入grand Children时，感觉就像我进入了“意大利面条”代码，从一个视图模型中加载了太多。我认为正确的做法是为父母、孩子和孙子创建一个视图模型，将他们分开并使他们可重用

---

我的问题是，父视图模型应该先加载子视图模型，然后让子视图模型加载孙子视图模型，还是应该有一个视图从单独的父视图到子视图再到孙子视图进行组合和级联？Ie一个视图应该分别加载三个视图模型，还是应该有一个专用的父视图模型调用所有三个视图模型并加载它们，并且或多或少地相互独立？我在这里寻找最佳实践，因为SPA理念对我来说相对较新。

现在宣布最佳实践还为时过早。。。尤其是当应用程序的实际工作流和性能特征未知时（此时可能未知）

一般来说，我们认为最好是每个VM加载它所需的内容，而不是依赖主VM来提供从属VM。这里的直觉是，您将其分解为单独的虚拟机，以便它们可以执行自己的职责。。。所以让他们去做吧。主虚拟机成为其子虚拟机的协调器，并尽可能远离其实现细节

我们打算在下个月左右发布一个名为“TempHire”的新样本，该样本以“热毛巾（ette）”为基础，可能会提供一些指导。这个时机可能不适合你。但你可以找到答案），我将总结（并过于简化）与你的问题相关的样本特征：

主VM与根实体（在您的情况下是父实体）关联

主VM接收一个“datacontext”（工作单元[UoW]），该工作单元专用于该根实体的工作流，并标有根实体的ID

“工作单元经理”根据根实体ID创建和跟踪UoW。如果您请求父级1的UoW，它将为您提供正在跟踪的UoW，或者为您创建一个新的UoW

这使得子VM可以很容易地以一种相当解耦的方式与主VM以及彼此共享数据上下文。主机不必通过嵌套VM链传递UoW。相反，每个VM都被注入“工作单元经理”，并可以通过父ID向“工作单元经理”请求UoW；它将获得“其他所有人都在使用”的UoW

现在，任何VM都可以通过向UoW请求数据来加载它所需的任何数据（或从UoW缓存中的数据中获益）。VM不必“思考”它是第一个还是最后一个请求数据，数据是否在缓存中，数据是否在开始时或根据需要检索。UoW可以封装这些细节，公开简单的“查询”方法供VM使用

当然，UoW应该提供适当的“刷新”方法来应对陈旧性。。。它对每个应用程序中的每个类型都有不同的定义

我们倾向于“沙箱”每个任务的UoW，这些任务通常围绕根实体进行。因此，父级-1的主VM有自己的UoW和自己的EntityManager，而父级-2的主VM有自己的UoW和自己的EntityManager。通过这种方式，用户可以同时处理父级1和父级2（例如，在更新订单456的同时创建订单123），并且可以独立处理，而无需混合更改

“工作单元管理器”使用嵌入式EntityManager（EMs）创建UoWs。它使用名为“EntityManagerProvider”的助手服务创建新的EMs。“EntityManagerProvider”负责创建新的EMs，并向其填充“全局数据”，如参考列表（例如，状态、状态代码、颜色等）

“EntityManagerProvider”（EMP）在内部保留一个只读的“主EM”，其中包含源元数据存储和这些静态引用列表的规范版本。它创建的新EMs通常是这个隐藏主EM的副本。因此，整个系统只对元数据发出一个请求，对那些静态引用列表发出一个请求。EMP负责将源材料分发到其创建的新EMs

---

你需要多少？我不知道。

现在宣布最佳实践有点早。。。尤其是当应用程序的实际工作流和性能特征未知时（此时可能未知）

一般来说，我们认为最好是每个VM加载它所需的内容，而不是依赖主VM来提供从属VM。这里的直觉是，您将其分解为单独的虚拟机，以便它们可以执行自己的职责。。。所以让他们去做吧。主虚拟机成为其子虚拟机的协调器，并尽可能远离其实现细节

我们打算发布一个名为“TempHire”的新样本，该样本源于“热毛巾（ette）”