后台即服务

Controller/Presenter 负责逻辑的处理，Model 提供数据，View 负责显示。

MVVMMVVM 是 Model-View-ViewModel 的简写。相比于 MVC 悠久的历史来说， MVVM 是一个相当新的架构，它最早于 2005 年被由的 WPF 和 Silverlight 的架构师

John Gossman 提出，并且应用在微软的软件开发中。而 MVC 已经被提出了二十多年了，可见两者出现的年代差别有多大。

MVVM在使用当中，通常还会利用双向绑定技术，使得Model变化时，ViewModel 会自动更新，而ViewModel变化时，View也会自动变化。所以，MVVM模式有些时候

又被称作：model-view-binder 模式。

后台即服务

BaaS（Backend as a Service）是一种新型的云服务，旨在为移动和 Web 应用提供后端云服务，包括云端数据/文件存储、账户管理、消息推送、社交媒

体整合等。

产生这种服务的主要原因之一是因为移动应用的流行。在移动应用中，我们实际上只需要一个API接又来连接数据库，并作一些相应的业务逻辑处理。对于不同的应用产

商来说，他们打造 API 的方式可能稍有不同，然而他们都只是将后台作为一个服务。

在一些更特殊的例子里，即有网页版和移动应用端，他们也开始使用同一个 API。

前端作为一个单页面的应用，或者有后台渲染的应用。其架构如下图所示：

API 演进史

在早期的工作中，我们会发现我们会将大量的业务逻辑放置到View层——如迭代出某个结果。

而在今天，当我们有大量的逻辑一致时，我们怎么办，重复实现三次？

如下所示是笔者之前重构的系统的一个架构缩略图：

上面系统产生的主要原因是：技术本身的演进所造成的，并非是系统在一开始没有考虑到这个问题。

从早期到现在的互联网公司都有这样的问题，也会有同样的过程：

第一阶段：因为创始人对于某个领域的看好，他们就创建了这样的一个桌面网站。

这个时间点，大概可以在 2000年左右。

图 33: Backend As A Service

图 34: 重复逻辑的系统架构

图 35: API 演进史

要。这时由于当时的开发环境，以及技术条件所限，当时的网站只会是桌面模板的简化。

这时还没有普及 Ajax 请求、SPA 这些事物。

第三阶段：手机应用的制作开始流行起来了。由于需要制作手机应用，人们就需要在网站上创建 API。由于当时的业务或者项目需求，这个 API 是直接耦合在系统中的。

第四阶段：由于手机性能的不断提高，并且移动网络速度不断提升，人们便开始在手机上制作单页面应用。

由于他们使用的是相同业务逻辑、代码逻辑相同而技术栈不同的代码，当有一个新的需求出现时，他们需要重复多次实现，如下图所示：

图 36: 重复业务逻辑的系统架构

随后——也就是今天，各种新的解决方案出现了，如React、混合应用、原生+ Web 的混合式应用、他们的目的就是解决上述的问题。不过，这些解决方案只是为了解决在

前端中可能出现的问题，详细的内容可以见《前端演进史》。

而人们也借此机会在统一后台——因为我们可以借助于混合应用或混合式应用（即原生 + 内嵌 WebView，可以同时解决性能和跨平台问题）统一移动端，借助于响应式

设计的理念可以统一桌面、平板和手机端。

因此，我们需要的就只是这样的一个 API：

图 37: One API