关于前后端分离与模板引擎

Posted 2021-04-30 筑梦前端

随着不同终端（Pad/Mobile/PC)的兴起，对开发人员的要求越来越高，纯浏览器端的响应式已经不能满足用户体验的高要求，往往需要针对不同的终端开发定制的版本，为了提升开发效率，前后端分离的需要越来越被重视，后端负责业务/数据接口，前端负责展现、交互逻辑，同一份数据接口，可用于多个终端。

 传统的前后端：

　　后端是跟数据库跟服务器打交道的，前端是跟浏览器打交道的。但似乎他们的职责在以前甚至于现在都并不明确，虽然前端是跟浏览器打交道，但是最终浏览器拿到的页面是服务器通过模板生成的一个临时静态页面而已。所以，实际上后端也掺和进来了，因为他要处理模板。当然，一般传统上的开发协作模式有两种：

一种是前端先写一个静态页面，写好后，让后端去套模板。静态页面可以本地开发，也无需考虑业务逻辑只需要实现View即可。不足是还需要后端套模板，这些前端代码后端需要浏览一遍，以免出错。

另一种协作模式是，前端直接去写模板，这样做的问题在于，前端编写过程中很依赖与后端环境，如果当后端没写完的情况下，前端几乎没法干活。

在做前后端分离时，第一个关注到的问题就是 渲染，也就是 View 这个层面的工作，模板引擎、前后端分离、单页模式，它们本应是三个完全分离的概念，但确实有很多现代 Web 项目同时使用了这些技术，于是它们的概念就经常被混淆。虽然它们各自并不闪耀，但当它们一起使用时确实可以成为现代 Web 中一种优秀的实践。

模板引擎

　　模板引擎是相当古老的东西了，现在能看到的很多后端编程语言其实都是基于模板引擎的。但这种语言级的模板引擎其实很难让开发者满意。以前写 ASP 的时候觉得用程序把数据库查询出来的数据填入页面中是一件很痛苦的事情。不是写出一堆凌乱的标签就是程序里做一堆字符串拼接。如果再考虑上内容的安全性，要做各种过滤和转义，简直会让人奔溃。

前后端分离

　　前后端分离的故事得从 Ajax 说起。在 Ajax 流行起来后，大家都开始了「无刷新」之旅。当时大部分网站都是以链接形式跳转的时候，自己使用「无刷新翻页」觉得已经很先进了。后来无刷新翻页也渐渐开始烂大街，百度搜一下可以搜出一坨东西，于是就开始考虑全页面的无刷新操作。渐渐地「Web 接口」这种东西出现，但是此时的「接口」其实主要还是直接输出 html，并没有考虑结构化之类的东西

单页模式

　　单页模式是前后端分离的一种应用。而单页应用最主要的特点就是局部刷新，这通过前端控制路由调用AJAX，后台提供接口便可以实现，而且这样的方式用户体验更加友好，网页加载更加快速，开发和维护成本也降低了不少，效率明显提升。

 

 

前后端分离的实现对技术人员尤其是前端人员的要求会上升一个层次，前端的工作不只是切页面写模板或是处理一些简单的js逻辑，前端需要处理服务器返回的各种数据格式，还需要掌握一系列的数据处理逻辑、MVC思想和各种主流框架。

 

优势与意义

1、彻底解放前端

　　前端不再需要向后台提供模板或是后台在前端html中嵌入后台代码

2、提高工作效率，分工更加明确

　　前后端分离的工作流程可以使前端只关注前端的事，后台只关心后台的活，两者开发可以同时进行，在后台还没有时间提供接口的时候，前端可以先将数据写死或者调用本地的json文件即可，页面的增加和路由的修改也不必再去麻烦后台，开发更加灵活。

3、局部性能提升

　　通过前端路由的配置，我们可以实现页面的按需加载，无需一开始加载首页便加载网站的所有的资源，服务器也不再需要解析前端页面，在页面交互及用户体验上有所提升。

4.降低维护成本

　　通过目前主流的前端MVC框架，我们可以非常快速的定位及发现问题的所在，客户端的问题不再需要后台人员参与及调试，代码重构及可维护性增强。

温馨提示：文章素材来源于网络，版权归原作者所有！