JavaScript 客户端 MVC 框架调查
如果您的目标是创建一种客户端体验,而对服务器状态的更新是次要的,那么 Spine.js 可能是一种更好的选择。如果仍然使用服务器来检查状态变化的有效性则 Backbone.js 可能更适合。Spine.js 提供了响应性更好的 UI。但是,如果显示成功删除某个元素,只是让服务器发送一个响应,不允许您删除该项,因为该项正在被其他人使用,那么会发生什么?针对这个问题存在一些应急方案,但是通常来讲 Spine.js 更加适合用户操作自有(而非共享)数据。Spine.js 的一个常见用例就是购物车,其中所有验证都可以在客户端处理。 Knockout 人们可能会争论目前为止讨论的这些工具是否是原本意义上的真正的 MVC 框架。Knockout 明确实现了模型-视图-视图-模型 (MVVM),而不是经典的 MVC。但是,不要因此而妨碍到您的决策制定。在选择框架时,更重要的是查看所提供的功能而非首字母缩略词或分类。 Knockout.js 在熟悉 MVVM 模型的 Microsoft .NET 开发人员之间特别受欢迎。对于主要问题是将模型状态通过声明的方式绑定到视图用例,Knockout.js 是非常好的选择。Knockout.js 对于前面提到的示例待办事项应用程序是非常理想的选择,该应用程序的主待办事项列表的子集都有自己的视图,在删除某个待办事项后需要更新所有的列表。 在 Knockout.js 中,您将创建模型、视图模型和视图。与在 Spine.js 和 Backbone.js 中一样,负责处理业务逻辑、验证和与远程服务器交互的 Ajax(假设您不仅仅是创建一个本地应用程序)。视图模型代码负责保留和操作模型数据。例如一个视图模型可能包含添加、编辑以及从列表中删除内容项的方法。视图模型非常贴近于传统的 MVC 架构中的控制器。视图就是一些模板,包含将信息呈现到屏幕的标记。在 Knockout.js 中,这些可以通过声明的方式绑定到视图模型(方便入门)。一些学员可以在一个小时内掌握并使用 Knockout,并可在三个小时内构建非凡 (non-trivial) 应用程序。 一般来讲,Knockout.js 比较适合较小、较简单的项目。人们往往将 Backbone.js 或 Spine.js 用于更大、更复杂的项目。也就是说,有经验的 Knockout.js 开发人员可以创建非常复杂、同时又易于维护的应用程序。如果考虑使用 Knockout.js,您也应当考虑 Angular.js 和 Sammy.js(参见 参考资料),后两者是两种相对轻量级、易于启动的框架。 Batman.js Batman.js 是一种有趣的新框架,由 JSConf 在 2011 年推出,但是又经过了几个月的时间才能够通过下载获取。Batman.js 已经开始受到一些喜欢并得到开发 MVC 应用程序的程序员的关注。表面上看,Batman 在易于入门、支持视图声明绑定方面与 Knockout.js 类似。Batman.js 提供了一些其他功能,包括可选的全栈 (full-stack) 框架,用于自动代码生成器、构建工具甚至后端 Node.js 服务器代码,可以实现您的服务器端 API。 和 Knockout.js 一样,Batman.js 也使用视图绑定。清单 3展示了一些样例视图代码。 清单 3. Batman.js 中的视图代码示例
清单 3中的代码是有效的 HTML5,包含一些额外的属性,供 Batman 绑定数据和事件。在 Batman.js 中,您的应用程序包含模型、视图和控制器。模型支持验证功能,能够实现生命周期事件,包括一个内置的恒等映射 (identity map),并且可以被告知(主动记录样式)如何坚持使用 、 选择一种 JavaScript 框架 如果您正在从事一个长期的大项目,那么了解 Backbone.js 或 Spine.js 很有必要,因为它们获得了广泛的采用,可以解决您可能遇到的问题。然而,即使有了这些项目,您要明白您不是有必要使用一个成熟的服务器端 MVC 框架,而是还需继续编写基础架构代码。 尝试使用在视图中用了声明式绑定的框架将非常有必要。此类框架具有与 Backbone.js 之类的项目不同的优缺点。如果考虑使用声明式视图绑定,那么花些时间研究一下更新的 Batman.js 框架提供的额外功能。虽然 Batman.js 不像其他框架那么流行,但它正在快速发展,而且提供了比普通客户端 MVC 框架更丰富的特性。 在不同框架中进行原型化,感受一下这些框架的用法,这样做非常有必要。特别是对于客户端 MVC 框架来说,原型化是从不同选项中进行选择的最快速、最有效的方法之一。一种方法是让每个团队成员花一到两天的时间,使用不同的框架进行原型化,然后进行回顾并讨论结果。最坏的情况是,如果您还有一对框架需要从中进行选择,那么再额外花一天左右的时间构建二者的概念,直到选出最适合您的用例的框架。 考虑灵活性。仔细考虑您可以做哪些工作来降低对框架的依赖性,这对于许多框架来说是一个艰巨的任务。为将来 12 到 18 个月内迁移到另一个框架制定一个备份方案,以防您发现需求和所选的框架没有按照预期进行。 结束语 (编辑:晋中站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |