这是我参与「第四届青训营 」笔记创作活动的第1天
一：背景
在前端青训营的项目开展中，因为缺乏后端工程师，所以被迫变身全栈。于是就得到了跟数据库近距离接触的机会，在以前的开发过程中，很多时候因为前后端分离的原因，前端往往失去了第一手处理数据的机会，很多都是后端将数据处理好后再把结果返回给前端，但是由于前后端的数据处理思维有一定的差距，导致很多时候后端处理后的数据对于前端来说不能用来直接使用，需要进行进一步的处理。然而这个处理的过程既可以放在前端，也可以放在后端，于是在有些开发场景中就会出现一个扯皮的情况。
后端：我数据全给你了，你拼接一下就行了，我咋知道你展示的数据结构是咋样的呀？
其实数据的处理放在前端还是后端都有一定的道理，因为后端不可能完全的了解前端所需要的具体的数据结构是什么样子的，很多时候需要前端自己对这些数据进行合并。如果将数据处理全放在后端进行的话，当用户访问量大时，后端的压力就会过大。同时后端接口的数据有原子化趋势，造成一些前端的接口和业务分离，最典型的就是在app中，嵌套接口请求以及不同数据流的merge操作越来越多。基于restful架构，后端给出基础资源的接口，前段基于业务自己组合。 如今一个后端，基本上需要面向ios、Android、小程序、网页等提供接口。如果业务逻辑稍有变动，而业务逻辑的处理放在了后端，那么将不影响前端展示，只需要改后端即可。因此在需求改动时，后端效率要高于前端，并且如果有进一步扩展也有快速的解决方案。而对于前端而言，只需要对自己的ui负责，效率更高。
因此理论上前后端处理数据都有一定的优势，但是在没有使用数据中台的情况下，为了保证业务的稳定性与迭代效率，在后端处理数据对于安全性，稳定性以及可维护性的效果显然是更好的。
项目中的实际处理
以springboot为例子，在实际的编码过程中，我们可以在controller层，专门将数据处理成前端所需要的格式。以用户登录为例。在数据库层面上，后端会在dataobject中设置数据库的映射类。
在数据库的业务层，设置一个UserService层以及对应的类，用于处理业务层的交互，而在业务层处理完数据后，基本上就得到了一个包含前端所需要信息的处理结果。
但是为了保证前端数据的脱敏以及保证后端传递给前端的数据能够直接使用，需要在controller层进行进一步的处理。在这里我们使用的方式是增加一个专门的类，用来规范传递给前端的数据。这样前端获得的数据是进一步脱敏的且能够直接使用的数据。
