我最近一直在研究很多MVC for JavaScript框架，我非常喜欢Spine.js的整体感觉以及它使用CoffeeScript的事实。也就是说，我在这个阶段的主要关注点是我需要能够将MVC框架迭代地放入一个相当大的现有应用程序中。我在Spine.js上看到的大多数文档都专注于创建新的应用程序。
有没有人对最佳方法有任何建议;如果在某个地方有一个很好的教程也会很棒，但谷歌不是那个朋友。
或者这只是一个坏主意，在处理遗产时我应该去其他地方？虽然Angular没有以同样的方式点击我;然而，对于如何使用遗留应用程序迭代地使用它，它似乎非常直接。
答案 0 :(得分：1)
我认为“迭代地”执行它是一个不错的主意。我是一家公司的自由职业者，他们决定在几个版本上完成一个完整的UI返工。在第一阶段，计划放弃现有的JS并使用spine js作为MVC并且需要js作为AMD。到目前为止一直很好 - 但这个过程是“迭代地”。该项目/应用程序相当复杂，花了半年多时间（我参与了2.5个月以来）。
离开所有现有的JS并“迭代地”替换发布的功能是一个很大的错误。因此，我们遇到了多个问题。如果你有数百个js文件，内联脚本，依赖项，那么简单地抛弃它们要容易得多，因为你可以直截了当地判断你的新代码是否有效。否则你总是必须区分它的错误：新旧代码。
这也是造成本来可以避免或至少减轻的问题的原因：
产品所有者并不是真正了解状态，因为他看不到任何明显的进展。他只知道错误和不端行为。这对双方都不满意/令人沮丧。我一遍又一遍地听到一句话：“它在前一天/之前确实有效 - 现在不是”
您开始更新一些过时的库，插件有时会导致兼容性问题，因为API往往会发生变化，所以您必须在旧代码中修复它。意思是：在某些时候它开始感觉像是在解决问题，而不是开发一个酷/好的应用程序。多数民众赞成也非常令人沮丧。
花费的时间超过预期/估计。
您一直在开发依赖于最终不存在的旧代码。
我的个人建议是：不要迭代地这样做。为实时应用程序做热修复，并在单独的分支上开发新的应用程序。
答案 1 :(得分：0)
我无法看到任何没有明确的mvc结构的遗留应用程序如何符合spine.js或者主干或角度等等可能会让人失望。
迭代转换就像编写一个新应用程序减去用于定义应用程序GUI交互的样板内容一样。首先关注模型和控制器，方法是拉出适合MVC结构的组件。我建议尽早避免某些类似Spine的应用程序交互组件，并且根据脊柱惯例，一旦其他所有内容都可以使用，那么路由会更有意义。