溫馨提示×
您好，登錄后才能下訂單哦！
點(diǎn)擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“web前后端分離的必要性是什么”，在日常操作中，相信很多人在web前后端分離的必要性是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”web前后端分離的必要性是什么”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！
未分離時(shí)期
MVC，博主就不多做解釋了，在早期JSP+SERVLET中的結(jié)構(gòu)圖如下
大致就是所有的請求都被發(fā)送給作為控制器的Servlet，它接受請求，并根據(jù)請求信息將它們分發(fā)給適當(dāng)?shù)腏SP來響應(yīng)。同時(shí)，Servlet還根據(jù)JSP的需求生成JavaBeans的實(shí)例并輸出給JSP環(huán)境。JSP可以通過直接調(diào)用方法或使用UseBean的自定義標(biāo)簽得到JAVABeans中的數(shù)據(jù)。需要說明的是，這個(gè)View還可以采用 Velocity、Freemaker 等模板引擎。使用了這些模板引擎，可以使得開發(fā)過程中的人員分工更加明確，還能提高開發(fā)效率。那么，在這個(gè)時(shí)期，開發(fā)方式有如下兩種方式一:
方式二:
先說明一下，方式二已經(jīng)逐漸淘汰。主要原因有兩點(diǎn):
(1)前端在開發(fā)過程中嚴(yán)重依賴后端，在后端沒有完成的情況下，前端根本無法干活。
(2)由于趨勢問題，會(huì)JSP,懂velocity,freemarker的前端越來越少。
因此，方式二逐漸不被采用。然而，不得不說一點(diǎn)，方式一，其實(shí)很多小型傳統(tǒng)軟件公司至今還在使用。那么，方式一和方式二具有哪些共同的缺點(diǎn)呢?
I、前端無法單獨(dú)調(diào)試
在項(xiàng)目上線后，遇到一些問題。比如樣式出問題了，由于前端不具備項(xiàng)目開發(fā)環(huán)境，那么就有可能出現(xiàn)如下對話
前端:"我這里沒問題啊。后端，你那里正常么?"后端:"我這里不正常啊。要不你過來看一下吧?"前端:"一時(shí)我也看不出問題，我也沒環(huán)境，怎么辦?"后端:"你沒環(huán)境，坐我這邊調(diào)吧。"然后，前端就滿臉不爽的在你那調(diào)代碼了。更有些情商低的后端就直接在旁邊開摁手機(jī)，實(shí)在是。。。。。
總結(jié)，因?yàn)榍岸藷o法單獨(dú)調(diào)試。一方面開發(fā)效率降低。另一方面，還有可能引發(fā)公司內(nèi)部人員上的矛盾。
II、前端不可避免會(huì)遇到后臺(tái)代碼
比如前端可能碰到如下結(jié)構(gòu)的代碼
<body>
<%
request.setCharacterEncoding("utf-8")
String name=request.getParameter("username");out.print(name);
%>
</body>
身為前端，在頁面里看到了后臺(tái)代碼，必然內(nèi)心是十分不快的，這種方式耦合性太強(qiáng)。那么，就算你用了freemarker等模板引擎，不能寫JAVA代碼。那前端也不可避免的要去重新學(xué)習(xí)該模板引擎的模板語法，無謂增加了前端的學(xué)習(xí)成本。正如我們后端開發(fā)不想寫前端一樣，你想想如果你的后臺(tái)代碼里嵌入前端代碼，你是什么感受?因此，這種方式十分不妥。
III、JSP本身所導(dǎo)致的一些其他問題
比如，JSP第一次運(yùn)行的時(shí)候比較緩慢，因?yàn)槔镱^包含一個(gè)翻譯為Servlet的步驟。再比如因?yàn)橥郊虞d的原因，在jsp中有很多內(nèi)容的情況下，頁面響應(yīng)會(huì)很慢。
半分離時(shí)期
前后端半分離，前端負(fù)責(zé)開發(fā)頁面，通過接口(Ajax)獲取數(shù)據(jù)，采用dom操作對頁面進(jìn)行數(shù)據(jù)綁定，最終是由前端把頁面渲染出來。這也就是其他博客里說的，Ajax與SPA應(yīng)用(單頁應(yīng)用)結(jié)合的方式。其結(jié)構(gòu)圖如下
步驟如下:
(1)瀏覽器請求，cdn返回html頁面
(2)html中的js代碼以ajax方式請求后臺(tái)的restful接口
(3)接口返回json數(shù)據(jù)，頁面解析json數(shù)據(jù)，通過dom操作渲染頁面
ps：博主早期就是用jquery的ajax請求，然后這么做的。
為什么說是半分離的?
因?yàn)椴皇撬许撁娑际菃雾撁鎽?yīng)用，在多頁面應(yīng)用的情況下，前端因?yàn)闆]有掌握controller層，前端需要跟后端討論，我們這個(gè)頁面是要同步輸出呢，還是異步j(luò)son渲染呢?因此，在這一階段，只能算半分離。
這種方式的優(yōu)缺點(diǎn)有哪些呢?
首先，這種方式的優(yōu)點(diǎn)是很明顯的。前端不會(huì)嵌入任何后臺(tái)代碼，前端專注于html、css、js的開發(fā)，不依賴于后端。自己還能夠模擬json數(shù)據(jù)來渲染頁面。發(fā)現(xiàn)bug，也能迅速定位出是誰的問題，不會(huì)出現(xiàn)互相推脫的現(xiàn)象。
然而，在這種架構(gòu)下，還是存在明顯的弊端的。最明顯的有如下幾點(diǎn)：
(1)js存在大量冗余，在業(yè)務(wù)復(fù)雜的情況下，頁面的渲染部分的代碼，非常復(fù)雜。
(2)在json返回的數(shù)據(jù)比較大的情況下，渲染的十分緩慢，會(huì)出現(xiàn)頁面卡頓的情況
(3)seo非常不方便，由于搜索引擎的爬蟲無法爬下js異步渲染的數(shù)據(jù)，導(dǎo)致這樣的頁面，SEO會(huì)存在一定的問題。
(4)資源消耗嚴(yán)重，在業(yè)務(wù)復(fù)雜的情況下，一個(gè)頁面可能要發(fā)起多次http請求才能將頁面渲染完畢?？赡苡腥瞬环X得pc端建立多次http請求也沒啥。那你考慮過移動(dòng)端么，知道移動(dòng)端建立一次http請求需要消耗多少資源么?
正是因?yàn)槿缟先秉c(diǎn)，真正的前后端分離架構(gòu)誕生了
分離時(shí)期
在這一時(shí)期，擴(kuò)展了前端的范圍。認(rèn)為controller層也屬于前端的一部分。在這一時(shí)期
前端：負(fù)責(zé)View和Controller層。
后端：只負(fù)責(zé)Model層，業(yè)務(wù)處理/數(shù)據(jù)等。
可是前端不懂后臺(tái)代碼呀?controller層如何實(shí)現(xiàn)呢?
這就是node.js的妙用了，node.js適合運(yùn)用在高并發(fā)、I/O密集、少量業(yè)務(wù)邏輯的場景。最重要的一點(diǎn)是，前端不用再學(xué)一門其他的語言了，對前端來說，上手度大大提高。
于是，這一時(shí)期架構(gòu)圖如下
增加node.js作為中間層，具體有哪些好處呢?
(1)適配性提升
我們其實(shí)在開發(fā)過程中，經(jīng)常會(huì)給pc端、mobile、app端各自研發(fā)一套前端。其實(shí)對于這三端來說，大部分端業(yè)務(wù)邏輯是一樣的。唯一區(qū)別就是交互展現(xiàn)邏輯不同。如果controller層在后端手里，后端為了這些不同端頁面展示邏輯，自己維護(hù)這些controller，徒增和前端溝通端成本。
如果增加了node.js層，此時(shí)架構(gòu)圖如下
在該結(jié)構(gòu)下，每種前端的界面展示邏輯由node層自己維護(hù)。如果產(chǎn)品經(jīng)理中途想要改動(dòng)界面什么的，可以由前端自己專職維護(hù)，后端無需操心。前后端各司其職，后端專注自己的業(yè)務(wù)邏輯開發(fā)，前端專注產(chǎn)品效果開發(fā)。
(2)響應(yīng)速度提升
我們有時(shí)候，會(huì)遇到后端返回給前端的數(shù)據(jù)太簡單了，前端需要對這些數(shù)據(jù)進(jìn)行邏輯運(yùn)算。那么在數(shù)據(jù)量比較小的時(shí)候，對其做運(yùn)算分組等操作，并無影響。但是當(dāng)數(shù)據(jù)量大的時(shí)候，會(huì)有明顯的卡頓效果。這時(shí)候，node中間層其實(shí)可以將很多這樣的代碼放入node層處理、也可以替后端分擔(dān)一些簡單的邏輯、又可以用模板引擎自己掌握前臺(tái)的輸出。這樣做靈活度、響應(yīng)度都大大提升。
(3)性能得到提升
大家應(yīng)該都知道單一職責(zé)原則。從該角度來看，我們請求一個(gè)頁面，可能要響應(yīng)很多看后端接口，請求變多了，自然速度就變慢了，這種現(xiàn)象在mobile端更加嚴(yán)重。采用node作為中間層，將頁面所需要的多個(gè)后端數(shù)據(jù)，直接在內(nèi)網(wǎng)階段就拼裝好，再統(tǒng)一返回給前端，會(huì)得到更好的性能。
分離所帶來的缺點(diǎn)
在分析缺點(diǎn)之前，容博主先自責(zé)一下。博主拿著底層程序員的工資，想著架構(gòu)師，甚至是部門leader該考慮的問題了。博主有罪!ok，說重點(diǎn)。
先上結(jié)論，中小型軟件公司，慎用前后端分離架構(gòu)!慎用!
(1)人員問題
大家自己留意一下宣傳這種架構(gòu)的是什么級(jí)別的公司，中小型公司一般沒有這樣的前端資源來支撐這樣的架構(gòu)。如果強(qiáng)推這樣的分離架構(gòu)會(huì)導(dǎo)致一個(gè)后果，后端被硬逼著去學(xué)vue.js，node.js這些，白白增加后端的負(fù)擔(dān)。最后處理不好，會(huì)出現(xiàn)一個(gè)后端紛紛離職的場面，
(2) 產(chǎn)品迭代周期問題
中小型軟件公司，一般需要一個(gè)比較快的軟件迭代周期。采用分離架構(gòu)，增加了一個(gè)接口制定流程和前后端聯(lián)調(diào)流程。從本質(zhì)上來說，放慢了迭代周期。
(3) 前端需要學(xué)習(xí)業(yè)務(wù)
本來前端只需要掌管視覺交互的部分。現(xiàn)在因?yàn)閏ontroller層也歸前端管了，前端必須對公司的業(yè)務(wù)流程有深入的了解，才能準(zhǔn)確的寫出顯示邏輯。不過這樣會(huì)讓后端覺得，前端奪權(quán)，前端在混KPI。前端也必須要去學(xué)無聊的業(yè)務(wù)，不過正所謂有得必有失，前端因此也能夠站穩(wěn)腳跟?；蛟S正是因?yàn)榍昂蠖朔蛛x架構(gòu)的出現(xiàn)，前端可以朝著架構(gòu)師進(jìn)軍吧。
到此，關(guān)于“web前后端分離的必要性是什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！
免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點(diǎn)不代表本網(wǎng)站立場，如果涉及侵權(quán)請聯(lián)系站長郵箱：is@yisu.com進(jìn)行舉報(bào)，并提供相關(guān)證據(jù)，一經(jīng)查實(shí)，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號(hào)
手機(jī)網(wǎng)站二維碼
