前端同构MVC实践分析

　　1、同构的概念和意义

　　1.1、isomorphic 是什么？

　　isomorphic，读作［ˌaɪsə’mɔ：fɪk］，意思是：同形的，同构的。

　　维基百科对它的描述是：同构是在数学对象之间定义的一类映射，它能揭示出在这些对象的属性或者操作之间存在的关系。若两个数学结构之间存在同构映射，那么这两个结构叫做是同构的。一般来说，如果忽略掉同构的对象的属性或操作的具体定义，单从结构上讲，同构的对象是完全等价的。

　　同构，也被化用在物理、化学以及计算机等其他领域。

　　1.2、isomorphic java

　　isomorphic java（同构 js），是指一份 js 代码，既然可以跑在浏览器端，也可以跑在服务端。

　　图 1

　　同构 js 的发展历史，比 progressive web app 还要早很多。2009 年， node.js 问世，给予我们前后端统一语言的想象；更进一步的，前后端公用一套代码，也不是不可能。

　　有一个网站 isomorphic.net，专门收集跟同构 js 相关的文章和项目。从里面的文章列表来看，早在 2011 年的时候，业界已经开始探讨同构 js，并认为这将是未来的趋势。

　　可惜的是，同构 js 其实并没有得到真正意义上的发展。因为，在 2011 年，node.js 和 ECMA 都不够成熟，我们并没有很好的基础设施，去满足同构的目标。

　　现在是 2017 年，情况已经有所不同。ECMA 2015 标准定案，提供了一个标准的模块规范，前后端通用。尽管目前 node.js 和浏览器都没有实现 ES2015 模块标准，但是我们有 Babel 和 Webpack 等工具，可以提前享用新的语言特性带来的便利。

　　2、同构的种类和层次

　　2.1、同构的种类

　　同构 js 有两个种类：「内容同构」和「形式同构」。

　　其中，「内容同构」指服务端和浏览器端执行的代码完全等价。比如：

　　functionadd（a， b）{returna + b}

　　不管在服务端还是浏览器端，add 函数都是一样的。

　　而「形式同构」则不同，从原教旨主义的角度上看，它不是同构。因为，在浏览器端有一部分代码永远不会执行，而在服务端另一部分代码永远不会执行。比如：

　　functiondoSomething（）{ if（isServer） { // dosomething inserver-side } elseif（isClient） { //dosomething inclient-side }}

　　在 npm 里，有很多 package 标榜自己是同构的，用的方式就是「形式同构」。如果不作特殊处理，「形式同构」可能会增加浏览器端加载的 js 代码的体积。比如 React，它的 140+kb 的体积，是把只在服务端运行的代码也包含了进去。

　　2.2、同构的层次

　　同构不是一个布尔值，true 或者 false；同构是一个光谱形态，可以在很小范围里上实现同构，也可以在很大范围里实现同构。

　　-function 层次：零碎的代码片断或者函数，支持同构。比如浏览器端和服务端都实现了 setTimeout 函数，比如 lodash/underscore 的工具函数都是同构的。

　　-feature 层次：在这个层次里的同构代码，通常会承担一定的业务职能。比如 React 和 Vue 都借助 virtual-dom 实现了同构，它们是服务于 View 层的渲染；比如 Redux 和 Vuex 也是同构的，它们负责 Model 层的数据处理。

　　-framework 层次：在框架层面实现同构，它可能包含了所有层次的同构，需要精心处理支持同构和不支持同构的两个部分，如何妥善地整合在一起。

　　我们今天所讨论的 isomorphic-mvc（简称 IMVC），是在 framework 层次上实现同构。

　　3、同构的价值和作用

　　3.1、同构的价值

　　同构 js，不仅仅有抽象上的美感，它还有很多实用价值。

　　SEO 友好：View 层在浏览器端和服务端都可以运行，意味着可以在服务端吐出 html，支持搜索引擎的抓取。

　　加快访问体验：服务端渲染可以加快浏览器端的首次访问的渲染速度，而浏览器端渲染，可以加快用户交互时的反馈速度。

　　代码的可维护性：同构可以减少语言切换的成本，减小代码的重复率，增加代码的可维护性。

　　不使用同构方案，也可以用别的办法实现前两个的目标，但是别的办法却难以同时满足三个目标。