关于前后端分离的一些思考

参考资料：http://ued.taobao.org/blog/2014/04/full-stack-development-with-nodejs/　　

 

　　最近准备阿里的前端工程师面试（貌似跟黑客没神马关系？），所以来认真的看前后端分离。mark一些自己的思考，希望你看过之后也能对现在流行的前后端分离有一些自己的理解和思考。O(∩_∩)O

　　传统的前后端分离，稍有一些经验的web开发者都会用到，简单的说就是把页面代码和后台语言代码分开到不同的文件，由不同方向的工程师编码并维护。抽象一点来看，就是从物理层面来划分，将客户端（浏览器）执行的代码，和服务器执行的代码分开。

　　说到这个，不得不提MVC。MVC的定义很复杂，但是理解起来很简单：

　　　　1. M=>Model 数据库模型，将常用的数据库操作函数封装起来，为控制层提供数据。

　　　　2. C=>Controller 控制器，控制代码的逻辑结构，比如判断用户是否登录等，调用Model层的函数，获取数据加上页面代码，并且返回给客户端。

　　　　3. V=>View　　   表示层，简单的来说，就是页面代码。不过包含了一些逻辑，如for、if等，可以在Controller层中解释成完整的页面。

　　为了说明逻辑结构，此处盗图一张：

　　

　　

　　如今的前后端分离，是从职能上来划分。服务器端工程师所负责的后台，仅仅充当数据接口，即只起到Model层的作用。而前端工程师负责Controller层和View层。变化主要是在Controller层，即Controller层变成了前端工程师的菜。注意这个地方：Controller层虽然是由前端工程师开发和维护，但仍然是运行在服务器端的。

　　为什么要这样做？淘宝UED的博客有比较详细的阐述：在复杂的系统中，MVC三层的代码往往会混杂在一起，很难维护。而View层的代码严重依赖后台开发人员，必须有前后端人员沟通协调，才能完成开发（一般的开发步骤是由前端工程师编写页面，然后由后台工程师翻译成模板）。更多具体的此处不赘述，有兴趣的可以参考淘宝UED里的文章。

　　前后端分离后，前端工程师可以不依赖后台工程师，独立完成模板的编写。而后台工程师也可以专注接口的开发。（啊~通俗一点来讲，是将工作进一步细化，降低了前端工程师和后台工程师的依赖度~ 从此后台工程师的麻麻再也不用担心我还没把页面写好啦！）

　　但是又有一个问题~前端工程师不会写服务器端的代码肿么破？2012年，NodeJS的火热给了我们一个机遇。虽然NodeJS跟浏览器里用的那个Javascript基本不是一个东西，但是既然打着JS的名头出来混，自然有些关联。NodeJS可以用Javascript的语法来编写服务器端代码，可以和PHP、ASP.NET等类比。不过NodeJS里的npm是个很独特的东西，可以很方便的访问别人编写好的函数库和一些扩展资源。

　　所以在前后端分离之后，结构就变成了如下图所示。（没戳，我又盗图了）

　　听说这种工程师就变成了传说中的全栈工程师~~

 

　　恩，先到这儿，去吃饭了。淘宝UED关于前后端分离共有6篇文章，至此，分析完了第一篇。

　　来来，我们继续来看第二篇。

 

　　接着讲到了前后端分离中的一个比较重要的问题：模板渲染。

　　传统渲染方法是服务器端渲染，即从服务器端解析相应的模板语法，组装成页面发送到客户端。随着AJAX的风行，浏览器端渲染也越来越多。浏览器端的渲染可以这样理解：AJAX从服务器端获取数据，在浏览器内部用JS组装HTML代码，然后通过DOM将更改应用到局部。复杂一些的，会调用特定的JS类库来实现模板渲染。

　　传统的web开发中，模板渲染是个模糊地带，既可以属于前端，又可以属于后台，但哪个都离不开。随着现在的前后端分离思想，模板渲染被分到了前端。这个地方也要注意一下，前端是指前端工程师，而不是浏览器。在加了NodeJS层后，模板渲染的选择变成了用NodeJS渲染或者在浏览器中渲染。

　　但无论在哪里进行模板渲染，渲染出的效果应该是一样的。所以在第三篇，介绍了一个叫做ModelProxy的东西，可以保证渲染效果的一致。可以把ModelProxy理解为一套固定的模板语法，类似PHP中的模板引擎smarty神马的。

　　第四篇，讲了安全问题，提到了web前端的一些常见漏洞和在模板解析时候的解决方案，其实还是在介绍ModelProxy.

　　第五篇，针对不同的浏览器进行不同的渲染。第六篇，这种架构的实践。