架构:前后端分离-按照处理的逻辑内容划分

思考起因

本来我是个全栈,自己做一个项目,这个时候并没有什么前后端分离的问题。

但是,因为要做一个更大的项目,这个时候就要做工作任务分离的一些事情,所以开始思考这方面的事情

什么是前后端分离

1、前后端分离,是依据代码运行的地方

按照这种理解,前端的作用,便是写页面。
JavaScript,HTML,CSS这些都是在浏览器端使用,所以这些都应该由前端写。
而API这些都是运行在服务器端,所以都是后端来做。

2、前后端分离,是依据谁编写前端页面

在早期,前端写完页面还是要交付给后端去处理,将其添加到web后台中才能返回页面。
后来,出现了node,能够直接返回页面,前端便也开始写一些在服务器运行的程序

3、前后端分离,是依据所写代码的逻辑

在前端能够使用node直接返回页面的时候,好像前后端分离已经演化到了最终形态。
在这个形态下,只要定义好API接口,前后端编程人员需要交流的地方已经不多了。

但是,出现了新的模糊界线的情况。
在互联网变化速度越来越快的今天,公司都有专门的运营人员。
这些运营人员管理着网页的展示,活动等等。
例如,淘宝的运营就需要根据季节来变换淘宝首页的轮播图,以及下面的推荐栏等等。
本来这些轮播图信息和网页结果是写死的,如果不想以后每次修改都需要运营和前端交流,
那么就需要提供一个前端网页结构的管理界面。

这时候就引出了我新想到的一个划分方法,以前应该有人提出过,但是我没有看到相关说法

逻辑

数据展示逻辑

这个价格,应该用红色,还是蓝色显示。
这个图片点击之后,要不要跳转到什么页面,跳转到哪个页面。
响应布局、弹性布局、文档布局,是要用什么样子的布局方式。
在主页面的简要信息展示哪些数据,点进去之后又是展示哪些数据。

这些,我称之为数据展示逻辑

业务逻辑

商品一个怎样的对象,里面有什么信息。
库存单位是怎样的一个对象,它和商品是怎样的一个关系。
支付流程是怎样子的,需要和那些服务进行交互。
数据同步,数据一致性,等等。

这些我称之为业务逻辑

这两个概念是我想到不久的,可能会有很多不清晰的地方

前后端实际解决的问题

结合前后端遇到的新情况,和刚刚的两种逻辑定义方式,我们可以很自然的想到,
前端是处理数据展示逻辑的人,后端是处理业务逻辑的人。

新的工作由谁来做

我认为,这个前端网页结构管理,应该由前端的人负责

依据

这些网页结构更多的是存储的数据展示逻辑,并没有多少业务逻辑。
如果需要后端的参与,那么也只是需要后端写很多很多的贫业务逻辑接口。
但是这样的做法,前后端之间多了一层沟通。

第一种前后端交互的理解,已经被普遍抛弃了,我这里讨论第二种和第三种的对比

第二种理解的好处

谁在编写前端页面,谁就是前端,提供API接口的就是后端

好处

1、前端不需要学习数据库操作

第三种理解的好处

谁处理数据展示逻辑,谁就是前端,谁处理业务逻辑,谁就是后端

好处

1、减少前后端大量的交流

2、前端写代码的时候也更加自然和顺畅

3、需要修改的时候,只需要找前端

选择判准

商业世界讲究的是利润,高利润需要低成本和高效率
低成本需要能够使用低水平人才,减少人才后续培养成本
高效率需要减少交流成本

对于一个稳定的团队
学习成本是一次性的,交流成本是持续不断的
长期来看,交流成本远远多于学习成本

对于人员流动性高的团队
学习成本虽是一次性成本,但是人员流动性大,成本摊薄程度十分有限
交流成本虽是不断付出,可时间短,也不会多到哪里去

归根到底,这还是一个要具体情况具体分析的事情

夹杂私话

我倾向于,培养人更多的能力
一方面是因为我认为人才是万物的尺度,培养人才是有价值的事情
另一方面是因为,如果大家都不培养人,那么就会严重阻碍行业的向前发展
大环境变好了,就不用那么卷了

猜你喜欢

转载自blog.csdn.net/Gragon_Shao/article/details/112756422
今日推荐