我正在使用映射插件处理一个非常复杂的 Knockout.js 应用程序，以使用紧密反映服务器端域对象的深层对象图。我一直在改进我的模式，因为我去一些对我自己有点尴尬的环境来说效果很好的东西，但我想知道它是否是处理 MVVM Javascript 的一种好/坏的整体方法。
本质上，我的页面模式是有一个显示模块功能，它的作用有点像控制器 - 它拥有视图模型的层次结构并负责检测更改、对服务器进行 Ajaxing 更改并使用映射插件更新其视图模型图任何可能以 JSON 形式在响应中返回的后续变化。我这样做是因为我的域是这样的，当在服务器上验证时，图表的某个部分的微小变化可能会导致图表远处部分的更改/删除。发生这种情况时，我需要一个共同点来重新映射更改、向用户显示消息对话框等。
我所有的视图模型都是可实例化的函数，我已经设计了它，以便它们对所使用的页面或服务器一无所知（即它们不执行自己的 Ajaxing）。每个视图模型的构造函数通过映射选项创建其子级，并且每个级别都传递一个对其父级的引用。我已经实现了一个大多数视图模型使用的通用脏标志，并且当发生更改时，它们会将对自身的引用传递到链上的顶部可观察到的“脏视图模型”，该模块已订阅该模块。我知道这听起来有点奇怪，但这似乎是处理它的最佳方法，因为每个级别的项目都在不断地添加和删除，所以我不能在初始化时静态订阅属性。我不
从纯粹的效率角度来看，这并不是最好的。最简单的方法是每个视图模型在需要时直接调用模块中的函数，但这种耦合类型肯定是错误的。或者我可以将模块（或其相关函数）的引用传递给每个视图模型构造函数，然后视图模型调用它，有点像 Javascript 依赖注入。但这似乎太抽象了。这已经足够复杂了。
我是否应该寻找更高级别的框架（例如 Backbone）来处理这一切？注入模块引用真的太抽象了吗？或者这种构造事物的方式基本上是有意义的？我很想听听任何在类似具有挑战性的场景中工作过的人关于你是如何进步和改进你的模式的。
编辑：我应该澄清一下，由于各种原因，这个应用程序在“随用随存”模式下工作，其中给定级别的更改会导致一个视图模型（不包括其子视图）的即时离散 Ajax 帖子成为发送到服务器（这可能会返回一个结果，该结果表示对其他任何内容的更改）。尽管与纯粹的客户端操作相比，需要持续的 Ajaxing，但 Knockout.js 仍然使我的应用程序比我的 Olde 的 MVC 应用程序更优雅、可维护和可扩展。