梳理 50 年人机交互界面发展史，得出这个规律，开发框架的选择不再迷茫

LIYI

发布于 2020-02-11 15:38:40

1K0

发布于 2020-02-11 15:38:40

文章被收录于专栏：艺述论专栏艺述论专栏

“Pick the right tool for the job”

1、Library 与 Framework 的区别
2、人机交互方案的演变
- 2.1、DOS
- 2.2、Markup Language
- 2.3、Code Block
- 2.4、Code Behind
- 2.5、MVC
- 2.6、MVP
- 2.7、MVVM
- 2.8、关于 WPF
- 2.9、MVC 之后的其它框架
3、总结

1、Library 与 Framework 的区别

首先明确一个概念，什么是框架？

框架的英文是 Framework，与之经常并提的另一个词汇是 Library。两者的区别有哪些？

Library = 库，本质上是一些函数的集合，每个函数根据单一职责原则，仅负责一个事情。每次调用函数后，函数会把控制权交给调用者。

Framework = 框架，是一套完整解决方案，使用它的时候，需要把开发者的代码放到其中，框架会在合适的时机调用这些代码。

两者区别是：

You call Library
Framework calls you
框架的侵入性很高，但功能更强
类库的自由度更高，但需要做更多额外工作

类库或框架俗称轮子，程序员喜欢造轮子，但有时候又喜欢复用已有的轮子以提高生产效率。那么，在快速开发业务项目时，选择轮子的标准是什么呢？在前端这一块，是应该选择 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 之后的其它框架