我正在构建一个与DOM密切交互的Web应用程序，需要指导我的代码可扩展和可维护。
应用程序概述：在交互时，我有工具栏和覆盖图引导用户编辑页面，然后我将编辑后的页面发送回服务器。
到目前为止，我已经成功构建了我想要的东西，但它的JQuery全部捆绑在一起，我需要有关如何重写代码以使其可扩展和可维护的帮助。
到目前为止的研究：
我还需要某种事件池来管理所有这些事件。如果我使用JQuery的内置事件池“bind”，“trigger”，这是否会让我远离Zakas的想法，即只有我的应用程序核心才能访问我的JQuery库？
我应该考虑采用什么类型的框架来解决我的问题？
答案 0 :(得分：12)
你实际上问了不止一个问题。我目前正在分析＆＃34;我应该使用什么框架＆＃34;我们公司的问题。这比你想象的要多得多。以下是我到目前为止的内容，随着详细信息的获取，我将尝试更新此项目。
与此同时......
架构模式的问题与库或框架的问题不同。
出于多种原因，ARCHITECTURAL DESIGN PATTERNS 非常有用。一个原因是在模块中实现松耦合。 Mediator Pattern 中提供了如何实现松散耦合的一个很好的示例。
使用哪个框架的问题有很多决策点：
速度测试：
这些是我考虑的框架：
我决定将我的框架选择限制为：
但是......还需要对JavaScript LIBRARIES进行细分：
MVC是最常用的前端模式。但是，我的笔记还没有完整。即使我在查找上面列出的项目的使用情况统计数据时也遇到了问题。
Backbone.js （MVC）
更倾向于使用REST数据。 Backbone有自己的事件系统，因此与jQuery功能竞争。
Spine.js （MVC）
JavaScriptMVC（MVC）
MVC集成开发工具;与jQuery一起使用;高度模块化。还不确定它是否可以简单地被认为是一个图书馆......但爸爸喜欢！
AngularJS（MVC）
关注点分离，松散耦合和控制反转。双向数据绑定
SproutCore （MVC）
YUILibrary （MVC）
这实际上是整个YUI框架的一部分......但是在原source article中列出了。
Broke.js （MVC）
文档目前很差。
Fidel.js （MVC）
Sammy.js （MVC）
更倾向于使用REST数据。
KnockoutJS （MVVM）
问题：
模块化JAVASCRIPT： AMD，CommonJS 和基于Promise的实现
我仍在概述这个领域。但是，以下是我正在使用的一些领域。
问题：
创建WIDGETS＆amp;插件：
一旦你决定你的模块应该使用哪种AMD版本，你就可以开始写一些东西了。
问题：
一般说明：
我建议看一下你的每个框架如何实现各种模块。看看完成某些事情所需的代码。感觉对吗？感觉笨重吗？
我的初始感觉： 观察社区支持选项的趋势，使用，速度和广泛性...... jQuery领先一步。
目标：
最终目标是选择一个框架，任何/所有库，并定义一个加载和创建松散耦合的JavaScript模块的通用方法。
按风险量化成本：
直接量化成本很难，但你可以解释风险。在您最后的决定中，您还应该考虑上面列出的趋势。但是，总的来说，我会将成本分散到3个定义风险的领域：
风险：经过评估，您可以正确地解释为什么您可以将一个选项排列为低，中或高。
<强> @ErezCohen
我们是一家ASP.NET商店，因此我们将REST API用于RESTFUL后端。由于组件式JavaScript开发是未来，我们选择使用jQuery＆amp; RequireJS作为我们所有页面的标准基线。此外，我们在控制器中大量使用Deferred。
至于客户端MVC，提到的太多“框架”比其他任何东西都更加流行（许多人已经在使用中衰落）。此外，当需求决定而不是标准时，将MVC / MVVM功能视为一次性附加组件更有意义。而且，坦率地说，既然我们发现使Ajax调用变得容易，那么简单的数据绑定就会变得愚蠢（对于某些复杂的情况，唯一真正的好处是双向绑定）。此外，想想一旦这些框架不再流行，将这些框架分离出来会带来多大的痛苦。
当然，我们有自己的才能......你可能不会。如果您的工作人员对JavaScript不是很好，请尝试使用Angular，因为它是为“设计人员”而非程序员开发的。或者，如果您的团队能够自己滚动并想要一个控制器框架，那么jQuery Widget Factory非常有用。但是，为控制器简单地使用模块模式也很好（这就是我们所做的）。并且...它很有效......并且非常干净。