先后端彻底分离的思考

网站开发历程

一、杂合模式

早期的asp开发网站时期大可能是如此，
一个asp文件混合业务处理，页面显示，js动态交互；彻底杂合在一块儿；

一个请求对应一个asp文件，业务逻辑解析，动态输出html内容。

后期的php、早期的jsp也是如此模式；

 

二、webform模式

这个是微软asp.net时期的一个方式，本质上是封装html为服务器控件，动态生成html及相关提交和状态保持；

先后端分离，事件触发模式；

出发点是好的，可是这个模式问题太多。

简单的问题复杂化，致使你们学习成本增长，要单独取学习下服务器控件，这个彻底背离了html简单简洁的原则。

致使各类代码冗余，开发代码的灵活性也下降到不行。

随着后来无刷新ajax技术流行，微软渐渐也是放弃了这个提交submit的交互模式，尽管后来有scriptmanager等也是各类难受，

封装到最后还不如直接用html来的科学，方便。

学习成本也是标高，和底层了解html背道而驰。

慢慢的就淡出了你们的视野。

 

三、模板引擎模式

一套独立的模板语法，这个好多的都是独立的模板引擎（包括如今微软的razor其实也才如此，只能说mvc也是low）

大可能是基于本身开发的或者统一的模板引擎，将页面显示部分独立出来到单独html文件；

这个方式的好处多了取了，方便模板的统一管理，核心业务被单独分离出去；模板只完成显示任务；

服务器端完成页面解析生成HTML内容返回给客户端，

服务器端：数据+模板语法；

（说下asp.net mvc吧，路由机制真是太死板了。这个要表扬下nancy吧，人家的灵活性真是没谁了。

mvc再也不基于aspx页面的存在而是基于路由模式；

而后control的自动绑定model只能说太low，灵活性太差；增长减小字段就要重构一遍model；

view用一个集中的bag管理数据，也是难为做者了。而后就是htmlHelper了，又是服务器控件的翻版。

只能说本意是好的，如此而已。徒增长学习成本）

 

四、先后端彻底分离模式

服务器端：完成业务逻辑处理，返回数据(json)给客户端；微服务API；

客户端：模板引擎（vue好像正火）+数据（json)

这个模式好处N多，

最大的好处就是一套API，无限终端（只要你的API服务器够强大）

a、服务器减压，显示逻辑不须要客户端组装，彻底有客户端js完成；

b、一套api接口能够给各类客户端调用，app、web，gui等等；

c、客户端单独部署、api单独部署、甚至能够多前端部署；

d、业务逻辑服务器，相对独立的模块能够单独部署开发；

e、独立的认证服务器，基于auth2.0模式；单点登陆，统一认证；方便第三方调用集成；用户+权限；

f、方便版本升级，多版本并存，请求路径修改就好；API接口统一；

g、升级维护成本下降，界面只是完成显示，修改不会影响到业务逻辑；要知道你们对美的要求真是突飞猛进。

h、方便单元测试，mvc模式解决了这个问题；

 

总结:

多终端时代，无疑微服务API是最科学的选择。

服务器端渐渐只完成必须完成的工做，能不作的都分配到客户端部分完成，这样才是最好的选择。