前后端完全分离的思考

Posted running_zhang

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了前后端完全分离的思考相关的知识,希望对你有一定的参考价值。

网站开发历程

1、杂合模式

早期的asp开发网站时期大多是如此,
一个asp文件混合业务处理,页面显示,js动态交互;完全杂合在一起;

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

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

 

2、webform模式

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

前后端分离,事件触发模式;

出发点是好的,但是这个模式问题太多。

简单的问题复杂化,导致大家学习成本增加,要单独取学习下服务器控件,这个完全背离了html简单简洁的原则。

导致各种代码冗余,开发代码的灵活性也降低到不行。

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

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

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

慢慢的就淡出了大家的视野。

 

3、模板引擎模式

一套独立的模板语法,这个好多的都是独立的模板引擎(包括现在微软的razor其实也才如此,只能说mvc也是low)

大多是基于自己开发的或者统一的模板引擎,将页面显示部分独立出来到单独html文件;

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

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

服务器端:数据+模板语法;

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

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

然后control的自动绑定model只能说太low,灵活性太差;增加减少字段就要重构一遍model;

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

只能说本意是好的,如此而已。徒增加学习成本)

 

4、前后端完全分离模式

服务器端:完成业务逻辑处理,返回数据(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是最科学的选择。

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

 

以上是关于前后端完全分离的思考的主要内容,如果未能解决你的问题,请参考以下文章

Web系统开发构架再思考-前后端的完全分离

干货苏宁易购:前后端分离架构的落地思考

由React引发的前后端分离架构的思考

苏宁易购:前后端分离架构的落地思考

前后端分离的思考与实践

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