Javascript MVVM 设计模式 - 如何跟踪脏状态以及谁应该做 Ajaxing

我正在开发一个非常复杂的 Knockout.js 应用程序，使用映射插件来处理一个深度对象图，该图与服务器端域对象密切相关。我一直在完善我的模式，因为我去了一些对我自己有点尴尬的上下文来说效果很好的东西，但我想知道这是否是接近 MVVM Javascript 的好/坏的整体方法。

从本质上讲，我的页面模式是一个揭示模块函数，它的作用有点像控制器 - 它拥有视图模型的层次结构，并负责检测更改，Ajaxing 对服务器的更改并使用映射插件更新其视图模型图与任何流动更改，这些更改可能会在响应中以 JSON 形式返回。我这样做是因为我的域是这样的，当在服务器上验证图形的一部分时，图形的一部分的微小更改可能会导致图形的远程部分的更改/删除。发生这种情况时，我需要一个共同点来重新映射更改、向用户显示消息对话框等。

所有的视图模型都是可实例化的函数，我设计了它，使它们对使用它们的页面或服务器（即它们不做自己的Ajaxing）一无所知。每个视图模型的构造函数通过映射选项创建其子级，并且每个级别都传递对其父级的引用。我已经实现了一个通用的脏标志，大多数视图模型都使用它，当发生更改时，它们将对自己的引用传递到链上可观察到的顶部的"脏视图模型"，模块订阅了该模型。我知道这听起来有点奇怪，但这似乎是最好的方法，因为每个级别的项目都在不断添加和删除，所以我无法在初始化时静态订阅属性。而且我不想每次重新映射图形时都继续删除和重新添加订阅（这可能会变得很大）。

从纯粹的效率的角度来看，这不是最好的。最简单的方法是，每个视图模型在需要时直接调用模块中的一个函数，但这种类型的耦合必须是错误的。或者我可以将对模块（或其相关函数）的引用传递给每个视图模型构造函数，视图模型调用它，有点像 Javascript 依赖注入。但这似乎太抽象了。这已经足够复杂了。

我应该寻找一个更高级别的框架，比如Backbone来坐在这一切之上吗？注入模块引用真的太抽象了吗？或者这种构建事物的方式基本上是有意义的吗？我很想听听任何从事过类似具有挑战性的场景的人关于你如何进步和完善你的模式。

编辑：我应该澄清一下，由于各种原因，这个应用程序在"随用而保存"模式下工作，其中给定级别的更改会导致一个视图模型（不包括其子模型）的即时离散 Ajax 帖子发送到服务器（这可能会返回一个结果，代表对其他任何内容的更改）。尽管需要不断的Ajaxing而不是纯粹的客户端操作，但Knockout.js仍然使我的应用程序比我的MVC应用程序Olde更优雅，可维护和可扩展。