简介:
MV框架又是为何鼓起的呢？它的涌现，伴跟着一些 Web 产物逐步往运用方向生长，遇到了在 C/S 范畴雷同的题目：由于前端功用的加强、代码的膨胀，致使不得不做“前端的架构”这个事变了。常常有人质疑，在前端搞 MV有什么意义？也有人提出如许的疑问：以 AngularJS，Knockout，BackBone 为代表的 MV*框架，它跟 jQuery 如许的框架有什么区分？我 jQuery 用得好好的，有什么必要再引入这类框架？
汗青:
回复这些题目之前，先要理清一些汗青，前端从什么时刻最先有框架的？
初期前端都是比较简朴，基础以页面为事情单位，内容以阅读型为主，也偶然有简朴的表单操纵，
这个时期每一个界面上只要很少的 JavaScript 逻辑，基础不太须要框架。跟着 AJAX 的涌现，Web2.0的鼓起，人们可以在页面上可以做比较庞杂的事变了，然后前端框架才真正涌现了，以 jQuery 为代表，针对界面上罕见的 DOM 操纵，长途请求，数据处置惩罚等作了封装，也有专注于处置惩罚数据的Underscore，严格来说，这些都不能算框架，而是算库。
库和框架是有一些区分的：库是一种东西，我供应了，你可以不必，纵然你用了，也没影响你自
己的代码构造。框架则是面向一个范畴，供应一套处理计划，假如你用我，就得根据我的体式格局做事。
根据这个定义，jQuery 和 Underscore 都只能算是库，ExtJS 和 dojo 算框架。
MV*框架又是为何鼓起的呢？它的涌现，伴跟着一些 Web 产物逐步往运用方向生长，遇到了
在 C/S 范畴雷同的题目：由于前端功用的加强、代码的膨胀，致使不得不做“前端的架构”这个事变了。
许多做后端开辟的人对前端架构很不屑，以为前端只是很薄的一层东西，做架构干什么？什么，
不但要搞架构，还要搞 MVC？Java Struts 的 MVC 中，全部前端都只能算是 View 罢了，你还要在这个 View 内里离别模子和掌握器等其他东西？他们中的多半对这个很不屑，但 Web 前端跟着庞杂度的增添，许多处所跟客户端已没有本质区分了。
jQuery 的头脑体式格局是：以 DOM 操纵为中间
MV*框架的头脑体式格局是：以模子为中间，DOM 操纵只是附加
为何须要MV*框架？
所以回到谁人题目上，jQuery 满足了你的营业须要，你另有什么必要引入 MV*框架？
这个是要看产物范例的，假如是页面型产物，多半确切不太须要它，由于页面中的 JavaScript
代码，处置惩罚交互的相对远远凌驾处置惩罚模子的，然则假如是运用软件类产物，这就太须要了。
历久做某个行业软件的公司，平常都邑沉淀下来一些营业组件，重要体如今数据模子、营业划定规矩
和营业流程，这些组件基础都存在于后端，在前端很少有响应的构造。在以往的履历里，他们是有做MVC 的，也尝试做了一些界面组件，但做法比较过期，比方说运用 JSF 或许 GWT 如许的体式格局。
JSF 的题目是什么？它的题目并不在于界面跟逻辑夹杂，所谓的纵向切分组件，Polymer 这类纯前端框架也是这么切分的，它题目在于组件的天生和衬着不在统一个处所。所以，逻辑代码的位置很为难，假如这个界面简朴还好说，庞杂起来就很贫苦了，就是许多明显是前端逻辑代码，却须要经由历程后端去天生。
GWT 这类体式格局相对要好一些，它的题目是留给 UI 调治的余地太小了，比较缺少灵活性。
这类基于某种服务端手艺的组件化体式格局有一些局限性，比方它较大程度限定了前端的发挥，在早
一些的时刻，这类体式格局可以还不错，然则如今跟着时期生长，用户对前端用户体验请求越来越高，须要我们把很大一部份精神继承放回前端来。JSF 等计划的别的一个题目是绑定了某种服务端环境，很难切换到别的一种后端上，假如碰上要用 Hybird 体式格局开辟，想复用一些前端逻辑，险些毫无可以。
那末，我们看看纯前端的框架，看看都是怎样处理这些题目的。以 Google 为例，它推出了两个框架，Polymer 和 Angular，而且处于并行生长的阶段，这二者理念另有不小的差异，给不少人带来了疑心。
Polymer 切分组件的体式格局有点相似 JSF，它跟 HTML5规范中的 Shadow DOM 和 Element 有很大联络，这类切分组件的体式格局异常直观，每一个组件都是端到端的，包括 UI 和逻辑，直接安排到某个界面上就能用，这类体式格局很轻易被营业开辟人员接收，但内里的时序比较难处置惩罚。
比方说，有两个组件，内里各包括一个下拉框，有数据的联动关联，由于它们处在两个差别的组
件里，联动的处置惩罚代码就很难写，考虑到组件的特性，要只管隐蔽本身的内部完成，所以从外部猎取组件内部的某个元素要绕一层，而组件不能依靠其他外部的东西，所以到最后只要经由历程事宜去完成，这个联动代码写好了应该放在那里，也是个大题目。我们的例子仅仅是这么简朴，就要绕这么个大圈子才保证时序，假如场景比较庞杂，异常难以掌握。
假如一样的组件在某个界面被复用屡次，数据的一致性也很难保证，想象一下某个界面存在两个
一样的下拉框，离别处于差别组件中，二者的数据都须要离别去加载，这个历程是有糟蹋的，更严峻的是，假如这个下拉框对应的数据有更新，很难把每一个实例都更新一遍，这个处置惩罚历程是异常贫苦的。
Angular 框架处置惩罚题目的体式格局跟它有所差别，它是程度分层，所有这些数据接见逻辑都跟 UI 完整星散，所以可以很轻松地把这个逻辑代码写出来，这么一来，前面所述端到端的组件就完整退步，变成只要界面展示了。
看看适才遇到的两个题目，第一个，模子代码根据营业范畴举行离别，猎取的数据放在两个差别
的数组，然后经由历程双向绑定跟 UI 发作关联，假如 UI 上一个下拉框选中项发作变动，只须要监控这个取值项，然后更新另一个下拉框的取值列表即可，完整不须要绕弯子。纵然这两个处于差别模子中，也可以用相似后端的体式格局，采纳事宜总线等机制去完成通讯。
第二个更简朴了，复用的组件实在只要 UI，也就是说，只要 UI 是多实例的，模子实在只要一份，比方说一个区域的树形构造，纵然一个界面上同时有保护和运用两种功用，都可以同享统一份模子，当保护这边对数据举行了更新，就及时反应到模子中，然后由双向绑定再把这个模子同步到界面上的运用方去，全部历程清楚可控。
从合作关联上讲，许多前端开辟团队每一个成员的职责不是很清楚，有了前端的 MV框架，这个
状态会大有改变。MV框架的理念是把前端根据职责分层，每一层都相对照较自力，有本身的代价，也有各自发挥的余地。
为何多半做互联网前端开辟的同学们感觉不到 MV*框架的重要性呢，由于在这个合作体系里，
Model 的这一块不够庞杂，在传统软件范畴，Model 的部份是代码最多的，View 的相对少一些，而互联网范畴里，基础是相反的，所以 Model 这块沦为附加，假如重要在操纵 View 和 Controller，那当然 jQuery 这类框架比较好用了。
所以，常常看到有互联网产物的同学们讲前端 MVC，但举例的时刻，都比较牵强，许多时刻，
他们举出来的谁人 Model，实在都不能算真正的 Model，而是在操纵 View 的历程当中一些辅佐的模子，真正的 Model 是贯串前后端的。
归根结柢，前端 MV*框架带来的是一整套事情流程的变动，后端工程师也可以编写前端的模子
代码，把它跟后端完整买通，交互工程师处置惩罚 UI 跟模子的互动关联，UI 事情人员可以专注、无障碍地处置惩罚 HTML 源码，把它们以界面模版的情势供应给交互工程师。这一整套合作机制可以大大提高B/S 架构体系的开辟效力，假如再有外围的管控平台，临盆效力将真正踏进产业化的阶段。
到这个阶段，前端开辟人员的前途是什么呢？我以为有两种。拿服装行业来对照，假如你要的是一般的，就运用产业手腕批量临盆，运用 MV*框架，做好架构和组件重用，做得快，细节不是很考究。假如你想要更好的，有特征的，就须要名家设想，手工打造，异常精致，高端大气上档次。所以，这也就代表着前端开辟的两种生长方向。
摘自：web 开辟者
