应用程序概述：在交互时,我有工具栏和覆盖图引导用户编辑页面,然后我将编辑后的页面发送回服务器.
到目前为止,我已经成功构建了我想要的东西,但它的JQuery都捆绑在一起,我需要有关如何重写代码以使其可扩展和可维护的帮助.
迄今为止的研究：
> RequireJS – 我看过RequireJS,并认为这是一个很好的起点,让一切正常.
> JQuery – 无法摆脱这个令人敬畏的库.
> Nicholas Zakas关于可扩展JavaScript应用程序架构的演讲 – 很棒的想法,但我该如何实现呢？我是高级JavaScript的新手.
我还需要某种事件池来管理所有这些事件.如果我使用JQuery的内置事件池“bind”,“trigger”,这是否会让我远离Zakas的想法,即只有我的应用程序核心才能访问我的JQuery库？
我应该考虑什么类型的框架来解决我的问题？
@R_403_323@
同时…
架构模式的问题与库或框架的问题不同.
由于许多原因,ARCHITECTURAL DESIGN PATTERNS是有用的.一个原因是在模块中实现松耦合. Mediator Pattern中提供了如何实现松耦合的一个很好的例子.
使用哪个框架的问题有很多决策点：
> JavaScript Famework Usage
> Google Trends
> Comparison of JavaScript frameworks
速度测试：
> Slick Speed
> Task Speed
> Write your own test like this guy did
这些是我考虑的框架：
> Dojo
> jQuery：仅当包含“伞形”模块时才是框架(可以用作单独的库)
> YUI
> Mootools
> Prototype
我决定将我的FRAMEWORK CHOICES限制为：
> Dojo：Toolkit,Desktop,Mobil,Graphics&矢量
> YUI：开发人员工具,基础设施,实用工具,小工具,图库,项目
> jQuery：核心,UI,插件,图形,可视化
但是……还需要细分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)
问题：
>为什么没有那么少的直接MVVM实现？
>双向绑定与MVVM相同吗？
>如果是这样,为什么这些库中的一些(做双向绑定)认为自己是MVC？
模块化JAVASCRIPT：AMD,CommonJS和基于Promises的实现：
我仍在概述这个领域.但是,下面是我正在使用的一些领域的灵感.
> A previous question of mine
> ARTICLE: Writing Modular JavaScript With AMD,CommonJS & ES Harmony
> ARTICLE: My Thoughts on AMD
> ARTICLE: Creating large-scale JavaScript Applications
> PRESENTATION: AMD Patters by John Hann
> Essential jQuery Plugin Patterns by Addy Osmoni
问题：
> AMD有不同的’风味'(各种文章似乎都说是)？
>’基于承诺’是什么意思？
创建WIDGETS&插件：
一旦你决定你的模块应该使用哪种AMD版本,你就可以开始写东西.
> ARTICLE: Coding your First jQuery UI Plugin
> ARTICLE: The jQuery UI Widget Factory
问题：
>插件和小部件有什么区别？
一般注意事项：
我建议看一下你的每个框架如何实现各种模块.看看完成某些事情所需的代码.感觉对吗？感觉笨重吗？
我最初的感受：
观察社区支持选项的趋势,用法,速度和广泛性…… jQuery遥遥领先.
目标：
最终目标是选择一个框架,任何/所有库,并定义一个加载和创建松散耦合的JavaScript模块的通用方法.
按风险量化成本：
直接量化成本很难,但你可以解释风险.在您最后的决定中,您还应该考虑上面列出的趋势.但是,总的来说,我会将成本分散到3个定义风险的领域：
>熟悉：您的团队现在最熟悉的是什么？
>加速：在每个框架和库上“加速”需要多少额外的努力？
>许可：这里有任何障碍吗？
风险：一旦评估,您可以正确地解释为什么您可以将一个选项排列为低,中或高.
@ErezCohen
我们是一个ASP.NET商店,因此我们将REST API用于RESTFUL后端.由于组件式JavaScript开发是未来,我们选择使用jQuery& RequireJS作为我们所有页面的标准基线.此外,我们在控制器中大量使用Deferreds.
至于客户端MVC,提到的太多“框架”比其他任何东西都要多(而且很多都在使用中).此外,当需求决定而不是标准时,将MVC / MVVM功能视为一次性附加组件更有意义.而且,坦率地说,既然我们发现使Ajax调用变得容易,那么简单的数据绑定就会变得愚蠢(对于某些复杂的情况,唯一真正的好处是双向绑定).此外,想想一旦这些框架不再受欢迎,将这些框架分离出去会带来什么样的痛苦.
当然,我们有自己的才能……你可能不会.如果您的工作人员对JavaScript不是很好,请尝试使用Angular,因为它是为“设计人员”而非程序员开发的.或者,如果您的团队能够自己滚动并想要一个控制器框架,那么jQuery Widget Factory非常有用.但是,为控制器简单地使用模块模式也很好(这就是我们所做的).并且……它很有效……并且非常干净.
