乐学视频电商 2023-08-18 21:37:01

前后端分离，数据处理到底是该放在前端还是后端？

这是个架构设计问题，不是简单地回答“前端”或者“后端”就可以解决的。

一个理想的架构，是应该从业务和应用场景出发，平衡前端、后端和网络的负荷。

后端的服务逻辑要完整，每一个服务要具有“业务价值”，对应一个需求；

前端不能薄薄的一层皮，也不能像RichClient或者传统的C/S架构那么胖；

控制交互次数，单次交互的网络负荷又不宜过高，免得影响用户体验。

架构这玩意儿，空对空容易弄成哲学，所以这么讲有点泛泛而谈。在您给出的场景中，你的想法，他的做法，都有不当之处：

你认为前端就只做UI和交互，那么大量的计算尤其是临时性的计算就必然抛到后端处理了。举个例子：假设一下返回20行数据，同时返回数量和金额的汇总，如果在后端计算的话，就得一个for，累加20次；如果这个系统并发量还可以的话，那么耗费的计算资源就很可观了，这就是个潜在的性能隐患。

但是，把这个临时性的计算放到前端来处理，什么效果呢？for一下20次累加，现代浏览器执行得非常快的，并且，前端的一个 *** 作通常都以“分钟”为单位，就是说，你看完20条数据，再点翻页按钮，这过程起码要耗费几十秒到1分钟时间，对前端体验没有任何负面影响。这样子，前端就为后端减压了。为了优化 *** 作，前端还可以在for的时候，每显示一条，将sum字段累加一下，几乎是0代价。

所以说，前端也要负担一些数据处理任务的，当然，是负责临时性的，与该用户相关的数据处理，而不是大段的业务逻辑。

后端做法的错误之处在于，设计API的时候没有考虑业务。按您的描述，返回ID和具体数据，明显是同一个业务 *** 作所需要的，不用分成两次先返回ID，再根据ID逐条请求detail数据。换言之，他设计的这个API没有业务意义，粒度太细，只是数据库SQL的一种包装形式而已。那何不提供个通用的访问DB的API让前端直接跟DB交互算了。

我多年来的经验，所谓ArchitectureDesign，并不是什么分三层四层用什么框架脚手架那么表面，而服务层API设计是其中的核心工作，它包含了一个架构师对业务的理解、对全局的把握。Service一定要有服务/业务的概念，不是对应数据库的CRUD。

这里面还涉及到一个前后端沟通的问题。前端直接与用户打交道，需要什么数据、用户什么 *** 作习惯，都要体现在UI上。一定要把这种逻辑和使用习惯明确地传递给后端设计/开发人员，它们才晓得该提供什么粒度的API给前端使用。

最后，软件开发是一个团队行为，分析、设计、开发阶段都需要沟通沟通再沟通，不要遇到问题了就互相扯皮、甩锅。

---------------

传统的开发网站是前后端不分离开发就是我们常说的模板渲染，通过后台编程语言控制前端模板的数据渲染方式。

前后台分离主要通过api数据调用渲染前端代码，通常是使用JavaScript动态调用。

现在网站开发更加注重前后端分离，方便管理，各个岗位可以减少协调，提高开发能力。

我们在开发软件和app应用的时候一般都会采用不同的分离模式，下面我们就一起来了解一下，前后端是否分离都有哪些影响与作用。

前后端不分离

在前后端不分离的应用模式中，前端页面看到的效果都是由后端控制，由后端渲染页面或重定向，也就是后端需要控制前端的展示，前端与后端的耦合度很高。

这种应用模式比较适合纯网页应用，但是当后端对接App时，App可能并不需要后端返回一个HTML网页，而仅仅是数据本身，所以后端原本返回网页的接口不再适用于前端App应用，为了对接App后端还需再开发一套接口。

前后端分离

在前后端分离的应用模式中，后端仅返回前端所需的数据，不再渲染HTML页面，不再控制前端的效果。至于前端用户看到什么效果，从后端请求的数据如何加载到前端中，都由前端自己决定，网页有网页的处理方式，App有App的处理方式，但无论哪种前端，所需的数据基本相同，后端仅需开发一套逻辑对外提供数据即可。

在前后端分离的应用模式中，昌平镇电脑培训发现前端与后端的耦合度相对较低。

在前后端分离的应用模式中，我们通常将后端开发的每个视图都称为一个接口，或者API，前端通过访问接口来对数据进行增删改查。

由于后端提供的接口方式可能多种多样，同时开发人员在编写Node端代码访问这些接口的方式也有可能多种多样。如果我们在接口访问方式及使用上不做统一架构处理，则会带来以下一些问题：

1每一个开发人员使用各自的代码风格编写接口访问代码，造成工程目录及编码风格混乱，维护相对困难。

2每一个开发人员编写自己的mock数据方式，开发完毕之后，需要手工修改代码移除mock。

3每一个开发人员为了实现接口的不同环境切换(日常，预发，线上)，可能各自维护了一些配置文件。

4数据接口调用方式无法被各个业务model非常方便地复用。

5对于数据接口的描述约定散落在代码的各个角落，有可能跟后端人员约定的接口文档不一致。

6整个项目分离开发之后，对于接口的联调或者测试回归成本依然很高，需要涉及到每一个接口提供者和使用者。

<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=10">
<meta ;

请采纳

不分离。在传统的web应用开发中，大多数的程序员会将浏览器作为前后端的分界线。将浏览器中为用户进行页面展示的部分称之为前端，而将运行在服务器，为前端提供业务逻辑和数据准备的所有代码统称为后端。由于前后端分离这个概念相对来说刚出现不久，很多人都是只闻其声，不见其形，所以可能会对它产生一些误解，误以为前后端分离只是一种web应用开发模式，只要在web应用的开发期进行了前后端开发工作的分工就是前后端分离。其实前后端分离并不只是开发模式，而是web应用的一种架构模式。

1>>前后端分离的意思是，前后端只通过 JSON 来交流
同意其他几位，JSON 只是一种可选的协议，而不是唯一，也未必是前后端通信的最佳方案。
2>>组件化、工程化不需要依赖后端去实现有哪些好处或弊端？
前端的组件化、工程化，js 等代码越来越胖，有点类似于过去 C/S 时代的 fat client。所以这个问题相当于，计算是主要放在 client 好，还是 server 好？
Fat client 好，还是 thin client 好，取决于所开发应用、产品、系统的类型、规模和特点，其中一些权衡因素主要包括软件复杂度、人机交互模型、网络带宽、server 与 client 的处理能力等等。无所谓好坏，适合就好。
Client-side MVC 确实是一个趋势，Web 架构设计上的一个创新。