前端MVC框架Backbone 1.1.0源码分析(一)

2022-09-28 07:57:57

前言

如何定义库与框架

前端的辅助工具太多太多了，那么我们是如何定义库与框架？

jQuery是目前用的最广的库了，但是整体来讲jQuery目的性很也明确针对“DOM操作”，当然自己写一个原生态方法也能实现同样的DOM操作，换句话说，不管你用来还是不用，都不影响你整体的布局，或者是代码体系结构。
框架则是一套完整的解决方案，针对是某一个领域的，比如EXT，dojo，那么很明显，你要用就需要按照它的规则执行，不管是编码风格还是结构，有一定的约束力

一个老话题，前端为什么要用MVC

前端开发中呢，不可避免的都有在应用逻辑中加入显示数据的代码的情况，当项目规模愈发变大时，这种形式的代码变得越发的难以维护，因为任何在主干逻辑中的变更都可能影响到数据显示逻辑，反之亦然，当然不管什么模式最主要的还是分离职责
可能在大多数后端开发者看来，整个前端就是一个View层罢了，还在在这个View层中划分模型，控制器等等，是不是很不屑？
在几年前只做做网站的验证之类的功能的话我或许会说，是的那是我也不信，但是随着Web前端随着复杂度的增加，很多地方跟客户端已经没有本质区别了。
如果是单纯的页面型的产品，确实不需要那么复杂，编程嘛复杂即是错，针对不同项目我们应该就要明确不同的方案，就拿近几年出现的Hybird App来说，这种应用软件类产品，这就太需有良好的结构组织了，深有感触的是我自己手上就是Hybird App这种项目，基本都是AMD+各种设计模式的组合

此MVC非比MVC

MVC，模型 - 视图 - 控制器这个没哈好说的，基本概念大家都知道，PHP的zend,yii很多都是基于MVC的架构，但是这种的架构其实是把整个前端都都作为一个view处理了
所以如果单纯拿Smalltalk-80的MVC的概念去套用前端，也就不那么合适了

我们如何理解前端的MVC

前端架构出现的根本原因呢，前端被越来越重视，nodejs,混合应用类似phonegap这都是在侵占别的领域 - -，所以前端功能的增强、代码的膨胀，导致不得不做“前端的架构”这个事情了。

软件架构模式MVC(Model-View-Controller)

大概理解就是：Models用来处理数据，View将处理结果呈现给用户，Controller用来连接这两者。

所以整个流程：

用户在View上进行操作——比如在文本框输入数值或是点击按钮
Controller处理这个动作
Controller通过Model对数据进行增删改查，将其传递到View
View将数据展示给用户

大多数的前端jser感受不到MVC的重要性，最大的问题还是跟传统的观念有差别，模型不够复杂，不存在控制器的概念

当然直接说前端MVC还是有点牵强的，模型不是真正的模型，在操作View的过程中一些辅助的模型，真正的Model是贯穿前后端的

归根结底，我也不需要太深入的去讨论各种不同，但是前端MVC框架的出现带来的是一整套工作流程变更，后端工程师也可以编写前端的模型代码，把它跟后端彻底打通，交互工程师处理UI跟模型的互动关系，UI工作人员可以专注、无障碍地处理HTML源码，把它们以界面模版的形式提供给交互工程师。这一整套协作机制能够大大提高B/S架构系统的开发效率，如果再有外围的管控平台，生产效率将真正踏进工业化的阶段。

backbone

backbone是什么？

Backbone.js 是一个在JavaScript环境下的模型-视图-控制器 (MVC) 框架。任何接触较大规模项目的开发人员一定会苦恼于各种琐碎的事件回调逻辑、以及金字塔般的代码。而且，在传统的Web应用程序代码中，不可避免的都有在应用逻辑中加入显示数据的代码的情况。当项目规模愈发变大时，这种形式的代码变得越发的难以维护，因为任何在主干逻辑中的变更都可能影响到数据显示逻辑，反之亦然。

Backbone就是要来解决这样的代码耦合的问题。它通过提供一个控制层-显示层的框架，以及模版(template)来分离各自逻辑。这样的MVC框架类似于传统意义上桌面程序以及服务器端程序的程序框架。

这里只提backbone，至于什么mvp,mvvc模式，Angular,Ember,CanJs,我也研究不是很深入，就不误人子弟了

模型、视图、集合和路由器是 Backbone 框架中的主要组件

在backbone框架中，我们看不到控制器这个东东，在0.5版本之前好像是叫控制器，后来改成路由器了

可见backbone虽然号称MVC，但是也非正统啊

总的理解

模型Models进行数据处理，创建验证销毁或者保存到服务器

合集Collections用来枚举

通过Views来进行事件处理及与现有的Application通过RESTful JSON接口进行交互

backbone基本概念很容易理解，但是它并不会告诉你如何去架构一个应用，而仅仅只是在代码的逻辑组织上提供一种方案

所以正真把backbone用好，个人感觉难度还是比其余的一些框架要大很多

而且还有个最大的问题，结构冗余，Backbone要求你写很多样板代码，而这种代码其实很多时候是完全没必要的

好处自然就是灵活，社区大，插件多了

官方todos

http://backbonejs.org/examples/todos/index.html

这是个很经典的案例

先看todos需要实现的功能

1 添加任务

2 修改任务

3 删除任务

4 任务统计

这个是完全用backbone实现的，其实整体一看逻辑还是很清晰的

Model，Collection，View，View

backbone的实现

先来分解下todos的操作，通过用户输入信息，然后显示信息到页面，然后还可以删除修改

视图View寓意就很明确，展现内容，内容从哪里来的，模型里面取的，模型为什么会有数据，因为用户输入的，怎么知道用户输入，因为监听了

我们看看backbone的做法

首先是创建一个全局的Todo的collection对象

var Todos = new TodoList;

在视图层对用户行为的监控，从而对模型合集进行curd的一系列操作

Backbone.View.extend = {

        events: {

            "keypress #new-todo": "createOnEnter",

            "click #clear-completed": "clearCompleted",

            "click #toggle-all": "toggleAllComplete"

        },

        createOnEnter: function (e) {

            if (e.keyCode != 13) return;

            if (!this.input.val()) return;

            Todos.create({title: this.input.val()});

            this.input.val('');

        }

    }

如果按照MVC的最原始定义，view永远不会知道用户输入，比如鼠标操作和按键，所以这里很明显就违规了~~

所以在web开发中，我们是无法1：1的对应入座的，用户的输入必须通过监听窗口、文档和元素上的事件来获得

这里有个很MVC架构很不明确的点，控制器在哪里？Controller应该是View操作Model的中介？

所以backbone其实只能是看作为数据和逻辑相互分离的一种方案，减少代码开发过程中的数据和逻辑混乱

好吧个人见解~ 不喜勿喷~

附上：

Developing Backbone.js Applications

码农公寓

前言