“Pick the right tool for the job”
目录
1、Library 与 Framework 的区别
首先明确一个概念,什么是框架?
框架的英文是 Framework,与之经常并提的另一个词汇是 Library。两者的区别有哪些?
Library = 库,本质上是一些函数的集合,每个函数根据单一职责原则,仅负责一个事情。每次调用函数后,函数会把控制权交给调用者。
Framework = 框架,是一套完整解决方案,使用它的时候,需要把开发者的代码放到其中,框架会在合适的时机调用这些代码。
两者区别是:
类库或框架俗称轮子,程序员喜欢造轮子,但有时候又喜欢复用已有的轮子以提高生产效率。那么,在快速开发业务项目时,选择轮子的标准是什么呢?在前端这一块,是应该选择 vue,还是应该选择 React?
2、人机交互方案的演变
工具或框架的演变与当下要解决的业务需求的复杂度,是密不可分的。在大前端这一块,前端框架主要是处理人机交互的需求。再细一点,就是如何处理输入,如何处理输出。梳理一下计算机诞生以来人机交互方案的变化,有助于找到答案。
2.1、DOS
在最早的 DOS 时代,计算机没有图形界面,主要通过终端、即命令行交互:
这个时代的交互,就是输入一次,输出一次。
2.2、Markup Language
后来,操作系统有了图形界面,有了浏览器,有了页面,程序员设计了 HTML、CSS 这些标记语言,多媒体时代来临了,界面元素的表现能力更丰富了。
表现能力的提高,对人机界面的交互性提出了更高要求。人们开始要求软件有丰富的交互性、互动性。
2.3、Code Block
有没有见过这种披萨饼式的代码:
< HTML>
< HEAD>< TITLE>JSP 页面 < /TITLE>< /HEAD>
< BODY>
< %@ page language="java" %>
< %! String str="0"; %>
< % for (int i=1; i < 10; i++) {
str = str + i;
} %>
JSP 输出之前。
< P>
< %= str %>
< P>
JSP 输出之后。
< /BODY>
< /HTML>
早期设计带有后端数据驱动的网页,使用的ASP、JSP、PHP都是这种风格。HTML、CSS与后端代码混合在一起。
但时间长了,程序员就发现这种开发方式不高效,也不利于代码的维护。
2.4、Code Behind
程序员从来就是一批受折腾的人。随着 Code Block 缺点的呈现,Code Behind 风格开始诞生:
// UI
<a href="#" class="addcurrency oa-btn" oa-style="green">添加新币别</a>
// 业务逻辑代码
<script type="text/javascript">
$(document).ready(function () {
$('.addcurrency').click(function () {
$.oa.drawer.openUrl('AddCurrencyDrawer/', 'addcurrency', {
width: 300
});
});
});
</script>
在这段代码中,UI 与业务逻辑是完全分离的。它可以使 UI 页面与 js 逻辑分别独立开发,以此提高生产效率;另外,分享的代码显得更整洁了,逼格更高了。代表框架是 JQuery。
但这样的代码也有问题,需要将“addcurrency”这样的类名写死,错一个字符都不行。DOM 组件上有没有事件监听,需要全局搜索代码才能知道,这在代码可维护性上、可扩展性上来讲,并不能算是一个最优设计。
但从这里开始,程序员们的开发思想开始分化了:
1,一部分倾向于将逻辑代码与 UI 进一步分开,让他们独立行使单一职责,这是从“低耦合” 这一软件研发原则考虑的。
2,一部分却倾向于将逻辑代码与 UI 反向聚合,做为一个单一组件提供,这是从“高内聚”这一软件开发原则提出的。
这两种想法都没有错,只是在面临复杂的业务需求时,进行业务分析与抽象的层次不同而已。在相当长的一段时间内,以这两种思想为首,产生了许多框架及思想,最著名的当数 MVC。
2.5、MVC
如上图所示,MVC 将代码分享为视图(View)、模型(Model)、控制器(Controller)三部分。其中控制器用于承载业务逻辑,模型用于定义业务数据对象,视图用于渲染。
三者之间,视图、模型、控制器都有交互。有时候 View 触发事件 -> Controller处理业务逻辑触发数据更新 -> 不知道谁更新了Model -> Model 数据回到了 View -> View 更新。
MVC 理论上看似清晰,但是在承载复杂的业务逻辑时,会使业务逻辑的抽象工作变得异常复杂。程序员必须寻找新的方案。
2.6、MVP
此处 MVP = Model-View-Presenter。Presenter 这个单词参照微软 WPF 的定义,应译为“呈现者”。
如上所示,在 MVP 模式中,交互关系变少了。View 与 Model 不再直接发生关系。Presenter 承担了原 MVC 模式中 Controller 的职责。
2.7、MVVM
如上所示,是当下最流行的 MVVM 模式。最火的两个前端框架 Vue 与 React 均是这种模式。
MVVM 与 MVP 相同的是,两者都隔离了 View 与 Model 直接交互。不同点在于,在 MVP 模式中,视图需要 Passes calls to Presenter,Presenter 也需要主动 Update 视图;而在 MVVM 模式下,这部分工作通过一种双向绑定(Bi-direction data binding)的技术帮助开发者自动搞定了。
比起 MVP,MVVM 不仅简化了业务与界面的依赖关系,还优化了数据频繁更新的解决方案,甚至可以说提供了一种有效的解决模式。
除了MVVM之外,其实还有一种MVVMS。它是在MVVM的基础之上,加一个Service,代理对本地存储、其它跨机、跨应用模块、服务器的访问。
2.8、关于 WPF
前端 MVVM 框架是这几年火爆的,但 MVVM 这种软件开发思想很高就有。
最具代表性的是微软的 WPF。WPF(Windows Presentation Foundation)是微软推出的基于Windows 的用户界面框架,属于 .NET Framework 3.0 的一部分,是按照 MVVM 的思想设计的。在 WPF 中,界面布局基本全部用代码搞定,任何一个细节都能控制到。
而 .NET Framework 3.0,是微软 2006 年 9 月发布的。
2.9、MVC 之后的其它框架
如生物物种的自然进化一样,技术框架的演化并不是朝一个方向进行的。如上所示,除了 React 与 Vue 这两个著名的 MVVM 框架之外,还有:
3、总结
从近约 50 年的软件人机交互界面框架的发展历程来看,交互性在逐渐增强,交互复杂性逼迫程序员将业务逻辑的分析层次与抽象层次逐级降低。
但是同时随着生产节奏的不断加快,即使抽象层次降低了,开发效率却在不断提升。
这个矛盾点决定,框架在向着少侵入甚至无侵入的方向发展,目的在于可以使业务项目保持连续性,可以进行渐进式演化。
Vue 2.0 的定位,是渐进式的前端解决方案。什么是渐进式,如何理解?
就是对开发者的要求很少,对现有项目的要求很少。框架本身可以松散地提供很多功能,但是开发者却没有必要一下子学习和使用全部功能,只需要按需取用即可。
从这个角度考虑,目前快速开发迭代业务项目,前端框架这块 Vue 是一个不错的选择。
在未来,随着 5G 的普及,VR 等新交互场景的丰富。人们对软件的交互性要求会更高、更强,同时由于竞争的日趋激烈,对交付效率的要求也更快,在这种情形下,除了渐进式、无侵入别无选择。
程序员在造轮子的时候,应优先考虑 Library,其次才是 Framework;在选用轮子的时候,“Pick the right tool for the job” 是首要原则。
参考链接
https://mp.weixin.qq.com/s/HJHVcTZc6d6Wndc2U_LTGA
尤雨溪:Vue 2.0,渐进式前端解决方案
《基于 vue+go 如何快速进行业务迭代?》