最近在做一个项目。基于让用户用的舒服。后端的接口先做好。所以前端需要添加大量的逻辑。例如循环对比之类的逻辑。我想问的是。前端添加那么多逻辑好还是不好。逻辑应该放在前端还是放在后端更合理。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
6
603
收藏
你的描述有问题，过多是一个不好的量词，所以在你自己看来，这样的“量”的逻辑处理是不好的。但是你却没有给出一个例子说明这样的“量”到底有多大。
逻辑处理放在那不能一概而论，后端处理方便且对性能没什么影响的，放在后端可以。但如果对性能有影响的，就尽可能不要放在后端，因为后端是一对多的关系，逻辑处理消耗会叠加。
所以说，回到头来，还是你要跟后端开发相互协调，前端要适当的分担后端的计算压力，但又不影响用户体验。这可没有一劳永逸的解。
固定的思维模式都是认为后台是处理逻辑的. 放在以前, 可以这么认为. 因为以前的前端是比较弱的. 处理速度缓慢. 可是现阶段js的发展已经有了很大的进步.各种方便的类库更是锦上添花.
关于您的问题, 需要考虑因素很多.
谁实现起来方便? 后端和前端, 谁比较容易快速的实现.
考虑传输数据量的大小? 如果后台处理后,往前端传送数据很多. 那就前端实现.
后端实现, 是需要考虑传输问题的.
目前来说,前端js很强大了. 多数情况下,我们的做法是, 能在前端实现的, 绝不回传给后台实现. 要综合考虑. 也就是说,能一个人完成的, 绝不让两个人干. 两人就会出现意见不一致的问题.
就看通用接口定义在哪了，如果定义在出口api，逻辑得写在后端，如果接口定义在视图，逻辑就可以写在前端分担后端的计算压力，但业务或者数据模型出现一些变化前后端都要修改，有可能无法兼容之前的代码，总之推荐逻辑写在后端，前端的修改只对新增的接口负责。
商量着谁方便谁做，没什么应该谁做。
从后端提供api，通用性，合理性的角度来看问题，这样前后台在扯皮的时候也能做到有理有据！
对于一些既可以放在前端也可以放在后端的逻辑，就根据人手和进度等实际情况来具体分析吧。
个人觉得，只要不影响用户体验，前端就可以做。但是涉及到响应时间，请求过多之类的，还是后端做比较好吧。