盡量將邏輯在后臺去實現,而不是在前臺實現這種邏輯正確嗎？

盡量，不較真，

就是那種前臺后臺實現起來復雜度差不多，或者前臺實現起來可能稍微簡單一點的，都放在后臺去實現

比如剛才我要查詢一個 所有人，假如我之前有兩個接口，查詢男人，查詢女人，兩個接口返回的數據結構一致，舉個例子，不抬杠

在前臺就可以調一遍男人接口，再調一遍女人接口，然后將兩個數組組合起來

在后臺就是新建一個查詢所有人接口，然后在這個接口里面調用男人接口，女人接口，將數據組合，返回給前臺

我覺得這種事情在后臺做比較好，因為前臺代碼規(guī)范不好，代碼多顯得比較亂，而且放在前臺會發(fā)起兩次請求，對性能也不好；在后臺將它合并成一個請求更加簡潔優(yōu)雅，我覺得

回答

編輯回答

空痕

不是為什么是這個邏輯
不應該是男女某個標識 0 1/ 所有人 2
然后后臺一個接口去跑SQL查表2的數據然后返給前端麼
其實你這個案例來說的話,前后端都可以不涉及某些安全信息,性能方面也沒多大影響倆個請求和一個請求的區(qū)別
而且整合在后端也不一定說性能多快

2017年2月8日 03:13

編輯回答

尐懶貓

其實應該是有后端來做的, 畢竟少發(fā)一次接口.
實際呢后端應該是不愿意去做的. 也正常. 前端也好做用peomise all 也挺完美的沒啥大區(qū)別

2017年5月4日 19:40

編輯回答

別硬撐

前端少寫邏輯，一來后面不好維護，二來如果哪天需求變了，改前端代碼還需要重新發(fā)布太麻煩。

2018年3月28日 07:49

編輯回答

冷咖啡

盡量在后臺寫邏輯，后臺非要你前端寫，你還沒他資歷高，那就自己寫嘍

2018年3月3日 10:39

編輯回答

心沉

我以前的時候就遇到過這種。一心只想著增刪改查，一點邏輯都不愿意做的后端
個人覺得還是要去看實現邏輯。比如這個接口。
難道不應該是男人女人都在一個表里面嗎。。如果他們只有性別不同得話
然后
傳一個參數 -1男人
0所有人
1女人
這個樣子進行獲取數據不是會更好一點嗎？

2018年3月14日 20:34

編輯回答

青黛色

樓主沒有了解過SinglePage單頁應用嗎？做好團隊規(guī)范后，無論是重后端還是重前端都可以。相對來說，重前端的模式有助于減少服務器的開銷，可以有效地降低成本。

2018年5月19日 04:21

編輯回答

夏夕

正確。但是有時候，后臺不愿意做，你們前端又沒人給你說話的時候，就只好妥協(xié)了。。

2017年10月2日 18:43

編輯回答

有你在

沒有什么標準答案，你說你兩次請求，他說他設計目的不僅僅是支持你一個web，可能還要支持app或者提供服務給第三方，然后大家都不想改就出現了中間層。
但就這個例子而言，個人覺得是應該由后端實現類似于/person/?:gender的查詢接口，或者實現兩個接口，查詢性別和查詢所有，而查詢男人和女人沒什么邏輯差異的話大概是一個接口。

2017年12月23日 19:59