AngularJS与Backbone谁更适合


哪个框架更适合

将不同的思想和工具进行对比,是一种更好地理解它们的方式。在本文中,我首先将列举在创建web应用程序时需要重复进行的各项任务,随后为你展现Backbone和Angular将如何帮助你完成这些工作。

AngularJS与Backbone谁更适合

转载请注明出处:http://www.fed123.com/2015/03/09/2015_backbone_angular/

我们所尝试解决的问题

作为web开发者来说,我们的大部分工作都可以归结于以下的某个类别中:

  1. 实现业务逻辑
  2. 构建DOM
  3. 实现视图逻辑(声明式与命令式)
  4. 在模型与视图间进行同步
  5. 管理复杂的UI交互操作
  6. 管理状态和路由(routing)
  7. 创建与连接组件
    如你所料,大多数客户端框架都以某种方式帮助你完成这些工作。

backbone做了些什么

首先让我们看看Backbone为解决这些问题提供了哪些功能:

AngularJS与Backbone谁更适合
AngularJS与Backbone谁更适合

将最原始的Backbone与Angular直接进行对比有些不太公平,因此在本文中所指的Backbone实际上是Backbone + Marionette + 插件的这套组合。

业务逻辑

Backbone应用程序中的很大一部分业务逻辑由模型(model)和集合(collection)负责实现,这些对象往往对应着服务端后台的资源,它们将包含视图显示所必须的内容。

由于使用者必须扩展Backbone.Model和Backbone.Collection对象,因此造成了许多额外的复杂性。

首先,Backbone使用POJO(简单JavaScript对象)和Backbone model对象两种方式表现领域对象。在显示模板(template)、或是与服务端交互时需要使用POJO,而在需要使用可观察(observable)属性时(例如需要建立数据绑定的时候),则需要使用Backbone模型。

其次,Backbone推荐你使用不可变对象。由于Backbone不支持对函数进行观察,因此每次有某个属性发生改变时,与之相对应的推断(computed)属性必须被重置。这就为你的应用增加了许多额外的复杂性,也使得最终产生的代码难以理解和测试。除此之外,所有的依赖项必须以(”change:sourceProperty, this.recalculateComputedProperty)的形式显式地进行指定。

构建DOM

Backbone使用模板引擎构建DOM。虽然从理论上说,你可以选择你所中意的引擎,但基本上在大型应用程序中都会在Mustache和Handlebars这两者之间进行选择。Backbone中的模板定义通常不包含逻辑,并且多数是基于字符串的,不过这两点也并非必需。

视图逻辑

将视图逻辑划分为命令式与声明式逻辑是一种由来已久的方式(可以追溯到原始的MVC模式)。事件处理配置和数据绑定属于声明式,而事件处理本身则是属于命令式。不过Backbone并没有为这两者划分出一条清晰的界限,它们都由Backbone.View对象处理。

在模型与视图间进行同步

由于Backbone在本质上追求最简化,因此它本身并没有为数据绑定提供支持。这一点对于小型项目来说或许不是一个问题,毕竟你可以选择让视图负责对模型和DOM进行同步。但当应用程序的功能开始不断增加时,这种方式就很容易渐渐失控。

好在如今已经有各种各样的插件(例如Backbone.Sticklt)能够帮助Backbone解决这一问题了,因此你可以不用再理会琐碎的模型-视图同步操作,而是专注于复杂的交互工作。这些插件中的大多数都可以使用简单的JavaScript进行配置,因此使用者可以在它的基础之上创建一个抽象层,以满足你应用程序的需求。

在Backbone中使用数据绑定的一个缺点就是它们依赖于可观察属性,而另一方面,模板引擎又是使用POJO实现的。由于同时存在着两种与DOM交互的方式,经常会造成代码的重复。

管理复杂的UI交互操作

所有的UI交互操作都可以划分为简单交互操作(使用观察者同步(Observer Synchronization)方式进行管理)和复杂交互操作(必须使用流同步(Flow Synchronization)方式)两种类别。

如前文所述,简单交互操作是通过使用数据绑定和事件处理函数的Backbone.View进行处理的。由于Backbone本身没有硬性规定处理复杂UI交互的解决方案,你可以随意选择最适合你的应用的方式。有些人选择使用Backbone.View作为解决方案,但我建议你不要这么做,因为这种方式会造成Backbone.View的职责过多。我会倾向于使用主动控制显示(Supervising Presenter)模式管理复杂的交互操作。

管理状态和路由

Backbone包含了一个非常简单的路由器的实现,但它并不支持管理视图和应用状态的功能,必须要手动实现这些功能。因此在实际应用中经常会选择使用其它类库(例如router.js),而不是它自带的路由器。

创建与连接组件

在Backbone中,你可以自由选择最适合你的应用的方式创建并连接组件。这种方式的缺陷在于你必须编写大量的样板代码,而且为了保持代码的合理组织,必须始终遵循良好的代码规范。

Angular做了什么

现在让我们来比较一下,看看Angular是如何解决这些问题的。
AngularJS与Backbone谁更适合
AngularJS与Backbone谁更适合

业务逻辑

由于Angular没有使用可观察属性,因此在实现模型时没有这方面的限制。你不需要扩展某个类、或者遵循某个接口,而是可以自由地选择你喜欢的方式(包括使用现有的Backbone模型)。在实际开发中,多数开发者选择使用简单的JavaScript对象(POJO),这种方式有以下优点:

所有的领域对象都不依赖于任何特定的框架,因而更容易在不同的应用中重用。
POJO对象和与服务端交互的对象非常近似,因而简化了客户端与服务器的通信。
POJO对象将用于视图表示,因此无需实现toJSON方法。
推断属性可以用函数的形式表现

模板与视图

由于Angular没有使用可观察属性,因此在实现模型时没有这方面的限制。你不需要扩展某个类、或者遵循某个接口,而是可以自由地选择你喜欢的方式(包括使用现有的Backbone模型)。在实际开发中,多数开发者选择使用简单的JavaScript对象(POJO),这种方式有以下优点:

所有的领域对象都不依赖于任何特定的框架,因而更容易在不同的应用中重用。
POJO对象和与服务端交互的对象非常近似,因而简化了客户端与服务器的通信。
POJO对象将用于视图表示,因此无需实现toJSON方法。
推断属性可以用函数的形式表现

构建DOM

Backbone将DOM的构建与视图逻辑进行了清晰地分离,前者使用模板引擎实现,而后者则使用数据绑定与命令式的DOM更新操作实现。与之相反,Angular并未将这两者进行区分,它使用相同的机制和指令(directive)构建DOM,并定义声明式的视图行为。

视图逻辑

Angular对声明式与命令式的视图逻辑进行了清晰的划分,前者由视图处理,而后者由控制器负责。

这种划分看起来似乎有些刻意,但它确实是非常重要的。

首先,这种方式清晰地指出了哪些部分需要进行单元测试。嵌入在模板中的声明式逻辑(例如ng-repeat)无需进行单元测试,反之,为控制器编写单元测试通常是个好主意。

其次,所有的依赖都是单向的,即视图依赖于控制器,因此控制器并不了解视图或DOM的任何逻辑。这种方式促进了代码重用,也简化了单元测试。与之相反,Backbone.View经常需要对DOM节点进行操作,随后使用模板引擎对页面中的很大一部分进行重新渲染。

在模型与视图间进行同步

Angular包含了原生的数据绑定功能,与大厦多数其它客户端框架所不同的是,它并不依赖于可观察属性,而是使用了脏检查(dirty checking)方式。
AngularJS与Backbone谁更适合
Angular的脏检查方式有着以下一些优点:

模型本身不会意识到它已经成为一个被观察的对象。
无需在可观察属性之间指定任何依赖。
函数同样表现可观察对象。
但这种方式也带来了以下一些负面影响:

在与第三方组件或类库集成的时候,你必须保证Angular能够响应它们对你的模型的任何改变。
在某些情况下会带来性能方面的影响。

管理复杂的UI交互操作

如前文所述,控制器将负责实现UI元素的命令式逻辑。除此之外,还可以将控制器实现为一种主动控制显示模式,以协调复杂的UI交互。
AngularJS与Backbone谁更适合

####管理状态和路由

与Backbone类似,Angular自带的路由器功能非常基础,并不适合于创建实际的应用。令人欣慰的是,AngularUI Router项目填补了这一空白。它能够管理应用状态、视图,并且支持嵌套视图。换句话说,它能够满足你对路由器的全部功能需求。当然,和Backbone的情况一样,你并非只有这一种选择,你也可以选择其它的路由功能类库(例如router.js)。

####创建与连接组件

Angular包含了一个IoC容器,它与通常意义上的依赖注入方法非常相似,这就要求你必须编写模块化的代码。这种方式能够改善代码的可重用性和可测试性,也使你免于编写大量的样板代码。它的负面影响在于一方面增加了使用的复杂度,一方面削弱了对组件创建过程的可控程度。

总结

本文简单地介绍了Backbone和Angular如何处理我们在创建web应用时所遇到的各种问题。这两个框架在某些问题的处理上使用了截然不同的方案,Backbone在显示模板、创建数据绑定和连接组件方面给使用者更多的选择。与之相反,Angular为这些问题提供了规定的方案,不过在创建模型与控制器方面的限制就比较少一些。

谢谢!

转载请注明出处:http://www.fed123.com/2015/03/09/2015_backbone_angular/

欢迎关注皓眸学问公众号(扫描左侧二维码),每天好文、新技术!任何学习疑问或者工作问题都可以给我留言、互动。T_T 皓眸大前端开发学习 T_T

未经允许不得转载:皓眸大前端 » AngularJS与Backbone谁更适合

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址