摘要：从协作关系上讲，很多前端开发团队每个成员的职责不是很清晰，有了前端的框架，这个状况会大有改观。框架的理念是把前端按照职责分层，每一层都相对比较独立，有自己的价值，也有各自发挥的余地。
简介:
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 开发者
分享来自：https://d.bianzhifu.com/pdf/
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/92328.html
摘要：事件订阅发布者模式什么是读音类似于是一套构建用户界面的渐进式框架。与其他重量级框架不同的是，采用自底向上增量开发的设计。 MVC && MVVM 前端框架前端 MV*框架的意义 被误解的MVC和被神化的MVVM Vue.js新手入门指南 单页应用SPA的路由 单页面应用的路由问题 本文是在自己总结时，看了许多篇文章有了些体会，然后把我认为有意义的摘抄下来，文中很大部分摘录以上...
摘要：前端的工作更具有挑战性，方向更多样化假设我今年要入前端开发的坑这里强调前端是因为，现在很多，安卓开发加入大前端的这个称呼。安卓版微信在截稿之前是大概的版本最新是并且持续了年不变，据说是为了稳定。 作者：Jay（沪江开发工程师）本文为原创文章，转载请注明作者及出处 不好意思，没有像其他公众号一样赶着发文章，每年到这个时候总有一大波什么今年前端预测，技术框架预测什么的。我这次写这篇文针对的...
摘要：前端的工作更具有挑战性，方向更多样化假设我今年要入前端开发的坑这里强调前端是因为，现在很多，安卓开发加入大前端的这个称呼。安卓版微信在截稿之前是大概的版本最新是并且持续了年不变，据说是为了稳定。 作者：Jay（沪江开发工程师）本文为原创文章，转载请注明作者及出处 不好意思，没有像其他公众号一样赶着发文章，每年到这个时候总有一大波什么今年前端预测，技术框架预测什么的。我这次写这篇文针对的...
摘要：前端的工作更具有挑战性，方向更多样化假设我今年要入前端开发的坑这里强调前端是因为，现在很多，安卓开发加入大前端的这个称呼。安卓版微信在截稿之前是大概的版本最新是并且持续了年不变，据说是为了稳定。 作者：Jay（沪江开发工程师）本文为原创文章，转载请注明作者及出处 不好意思，没有像其他公众号一样赶着发文章，每年到这个时候总有一大波什么今年前端预测，技术框架预测什么的。我这次写这篇文针对的...
摘要：模式的目的是实现动态的程序设计，简化程序后续的修改和扩展过程，并且使模块能够被重复利用。视图的可视化表示，表示当前状态的视图。出现于年，最大变化在于代替了。其关键改进是数据绑定，也就是说，的数据状态发生变化可以直接影响，反之亦然。 MV模式的目的是实现动态的程序设计，简化程序后续的修改和扩展过程，并且使模块能够被重复利用。此模式通过简化程序使之变得更为直观。MV不是一种技术 ，而是一种...
阅读 3379·2021-11-22 09:34
阅读 650·2021-11-19 11:29
阅读 1350·2019-08-30 15:43
阅读 2232·2019-08-30 14:24
阅读 1866·2019-08-29 17:31
阅读 1223·2019-08-29 17:17
阅读 2616·2019-08-29 15:38
阅读 2728·2019-08-26 12:10
