我要问的问题是受到我最近使用Flex平台的工作（以及一些假装实现MVC的框架）的启发，但我认为这足以让具有各种专业知识的人参与其中。
很长一段时间以来，我都遵循了像Cairngorm这样的框架提出的范例 -
查看，绑定到单例模型的属性以及调度事件。 事件被前端控制器捕获，结果命令被执行。 命令调用服务，获取数据并提供模型。 该模型通过绑定隐式更新视图。
在我得到以下数据结构之前，这一切都很好听：
用户 有很多粉丝（用户） 跟随很多用户 有一堆照片 跟随许多地方
照片 有很多喜欢的人（用户） 有一个位置 有一个创造者 有很多相关的照片
地点 有很多照片 有很多粉丝
同样，使用Cairngorm提出的想法也不会有问题 currentUser，currentLocation和currentPhoto，只是绑定到它们。
问题出在观点本身。我有一系列复杂的“页面”视图，它提供了可以想象的钻取信息。例如，位置页面显示最新/流行照片的网格，关注者的面板以及基于拍摄这些照片的坐标的地图。问题出现了：
显然，出于性能原因，我无法获取关注特定位置的所有用户或位置可能拥有的所有照片。我预先提取了一些，其他的将由服务器按需提供。
我想深入了解同一个视图，例如点击关注者的头像页面时，我应该得到该用户照片的小网格，或者......但我在模型中只有一个currentUser。
这导致了一个问题，为什么我甚至需要绑定到中央单例模型？我不能只是将每个视图转换为一个响应者，即视图再次调度，但这次命令而不是提供模型，将直接提供调用视图。
不会有任何耦合，因为每个视图都会实现IResponder。该命令只需要一个IResponder，它将从调用它的事件中获取。
我所看到的“模特”将扮演不同的角色。它更像是一个缓存，一种用于本地存储的全局字典，在它从服务器发出请求之前将由命令检查。这样它可以节省一些对服务器的调用，但是，如果数据非常偶发，则同一数据将与其他数据一起一次又一次地获取。 （我可能在缓存中有一些用户数据，但一般情况下我会调用服务器以获取一组关注者数据，无论其中是否有一些我可能已经拥有，为了保持一致性）
欢迎任何有关这些想法的反馈
答案 0 :(得分：1)
我认为你的实际问题是：
这导致了一个问题，为什么我 甚至需要绑定到一个中心 单身人士模特？
您不需要绑定到中央单例模型。事实上，许多人声称这种方法很糟糕，会导致性能问题。绑定可能是一项昂贵的操作，因此将所有可绑定值放在一个位置会导致应用程序出现连锁反应。
Cairngorm似乎将你推向这个方向这一事实对Cairngorm来说是一个普遍的批评。在Cairngorm的辩护中，我认为没有理由 - 在Cairngorm架构内 - 如果你愿意，你不能拥有多个“全球数据单身人士”。我首先要避免反对反对单身人士的论点。
大多数后Cairngorm框架可以被视为对Cairngorm的回应以及尝试以不同方式做事。
答案 1 :(得分：1)
这不是一个真正的答案，因为问题不是一个问题。但是，如果你想看看'MVC'，你应该远离Cairngorm ，因为它在Flex的所有应用程序框架中实现了最糟糕的MVC模式。最好的例子之一（或者最糟糕的取决于你如何看待它）是他们使用Theo already blogged about的单例模型。
您应该查看RobotLegs或Parsley以获取正确的MVC架构。在我个人对架构的看法中，“模型”只是说“数据”的另一种方式。它只是一个为您的应用程序保存数据或状态的类。