關(guān)于將前端和后端保持在一起或分開，存在廣泛的意見分歧。唯一重要的是，這兩個(gè)組件對(duì)于開發(fā)成熟的應(yīng)用程序都是必需的。

考慮：緊密耦合的前端和后端

許多人認(rèn)為后端和前端的分離是一個(gè)壞主意，這兩個(gè)角色之間沒有太大區(qū)別。

以下幾點(diǎn)支持為什么前端和后端應(yīng)該保持在一起：

• 類似的概念和語法：功能抽象通過消除不必要的特征，將重點(diǎn)放在基本的項(xiàng)目功能上，成為主要幫助。為了解決這些問題，在客戶端和服務(wù)器環(huán)境中使用了類似的概念和語法。例如，ReactiveX是一種具有可觀察模式的API異步編程，可以用各種語言實(shí)現(xiàn)，這有助于在前面和后面的相同響應(yīng)式抽象上輕松構(gòu)建項(xiàng)目。
  ?
• 溝通不暢是最低限度的：通信需要完好無損，以實(shí)現(xiàn)無縫的應(yīng)用程序開發(fā)過程。前端和后端的劃分將造成溝通鴻溝，使兩個(gè)團(tuán)隊(duì)不了解或不清楚有關(guān)各自端變化的信息。將前端和后端保持在一起將減少此類錯(cuò)誤溝通的機(jī)會(huì)，從而促進(jìn)應(yīng)用程序的順利開發(fā)。
  ?
• 高效利用資源：聘請全棧開發(fā)人員進(jìn)行前端和后端耦合。當(dāng)考慮大型項(xiàng)目時(shí)，需要在客戶端和服務(wù)器端解決一些任務(wù)。在這種情況下，全棧開發(fā)人員從應(yīng)用程序的一部分跳到另一部分，沒有任何額外的開銷。在開發(fā)團(tuán)隊(duì)中擁有全棧開發(fā)人員既經(jīng)濟(jì)高效又省時(shí)。
  ?
• 高效的團(tuán)隊(duì)合作，完全擁有所有權(quán)：如果對(duì)業(yè)務(wù)需求有清晰的了解，前端和后端的集成是富有成效的。這樣，參與的多學(xué)科團(tuán)隊(duì)將迅速適應(yīng)開發(fā)環(huán)境，并完全擁有項(xiàng)目。開發(fā)團(tuán)隊(duì)一起工作更長的時(shí)間，以有效地交付產(chǎn)品。
  ?
• 適用于簡單和小型項(xiàng)目：對(duì)于簡單的 CRUD（創(chuàng)建、讀取、更新和刪除）操作或較小的代碼庫，耦合的前端后端方法綽綽有余，因?yàn)樵谶@種情況下，大多數(shù)任務(wù)已經(jīng)解決，不需要額外的輸入。
  ?
• 開箱即用的安全性：將前端和后端連接在一起具有許多安全優(yōu)勢。例如，在這種情況下，無法公開 API，從而保護(hù) API 免受任何類型的攻擊。

所以我們談到了前端和后端加入到現(xiàn)在的優(yōu)勢。但是，現(xiàn)代應(yīng)用程序開發(fā)模型由于其缺點(diǎn)，正在看到緊密耦合的前端和后端被其他方法取代。

以下是將前端和后端連接在一起的缺點(diǎn)：

• 在簡單網(wǎng)站的情況下，前端和后端加入是成功的。在網(wǎng)站上添加網(wǎng)頁會(huì)使系統(tǒng)效率低下，無法提供多種類型的內(nèi)容、圖像或其他媒體元素。
  ?
• 所有處理任務(wù)都由服務(wù)器在最終將內(nèi)容交付給用戶之前完成。這最終使服務(wù)器無法有效地處理多個(gè)用戶請求。
  ?
• 自定義的范圍較小，因?yàn)樵诤蠖藞?zhí)行的任何更改都會(huì)直接影響網(wǎng)站的前端。此外，任何開發(fā)更改或維護(hù)都需要比平時(shí)更長的時(shí)間。

為了處理大型項(xiàng)目，例如擁有數(shù)十億行代碼，前端后端緊密耦合將不起作用。由于大型項(xiàng)目太大，任何人都無法完全掌握。全棧開發(fā)人員將無法完全控制項(xiàng)目。

來源：呆伯特

在開發(fā)環(huán)境中分離前端后端

功能強(qiáng)大且高性能的Web瀏覽器具有增強(qiáng)的處理功能，有助于在Web應(yīng)用程序開發(fā)模型中將前端和后端分離后實(shí)現(xiàn)無縫運(yùn)行。

前端和后端分離的主要好處如下所述：

• 廣泛的技術(shù)專家覆蓋：在多層開發(fā)環(huán)境架構(gòu)中，復(fù)雜的技術(shù)負(fù)責(zé)任務(wù)。因此，為了創(chuàng)建一個(gè)復(fù)雜的系統(tǒng)，需要特定的技術(shù)專家。劃分前端和后端有助于獲得各自技術(shù)專家的程序員。此外，消除雙方可能對(duì)另一方施加的技術(shù)選擇的限制。從而使該過程在這樣的開發(fā)環(huán)境中順利進(jìn)行。
  ?
• 模塊性：由于此類開發(fā)模型中的組件或模塊是獨(dú)立的，因此更換模塊或?qū)δK進(jìn)行任何更改都是順利的。Web 應(yīng)用程序的后端模塊中的更改不會(huì)影響前端部分，反之亦然。因此，不會(huì)覆蓋或弄亂對(duì)方的工作。
  ?
• 快速開發(fā)和部署：由于各個(gè)團(tuán)隊(duì)在項(xiàng)目上并行工作并且完全連貫，這有助于快速同時(shí)開發(fā) Web 應(yīng)用程序，從而實(shí)現(xiàn)快速應(yīng)用程序部署。
  ?
• API 整合：隨著大量設(shè)備的可用性，需要對(duì)各種版本的代碼（網(wǎng)站，iOS應(yīng)用程序，Android應(yīng)用程序）進(jìn)行管理。其中大多數(shù)需要相同的代碼庫?；?API 的網(wǎng)站簡化了開發(fā)人員的一切，因?yàn)楝F(xiàn)在 API 處理代碼管理。因此，開發(fā)人員需要處理的代碼更少。

我們看到松散耦合的前端和后端帶來了許多主要的好處。

但是這種分離也帶來了一系列缺點(diǎn)，它們是：

• 與 API 的通信和代碼管理增加了團(tuán)隊(duì)的文檔開銷負(fù)擔(dān)。除此之外，沒有明確的方法來解決前端的 API 更改。
  ?
• 工作量隨著前端和后端的劃分而增加。為了提交任何更改，需要進(jìn)行兩次同步提交，而不是一次。
  ?
• 前端和后端的集成會(huì)導(dǎo)致錯(cuò)誤、進(jìn)度延遲，在最壞的情況下會(huì)導(dǎo)致開發(fā)失敗。此外，團(tuán)隊(duì)之間的溝通效率低下。

分還是分？選擇什么

正如我們所看到的，前端和后端的鴻溝可能沒有什么好處。但這些好處可以擴(kuò)展到獨(dú)立升級(jí)、熟練的員工集成、可重用的 API 等。最重要的是，較少的依賴項(xiàng)減少了開發(fā)塊的機(jī)會(huì)。

我們并不是說這些擴(kuò)展優(yōu)勢使前端和后端與前端后端連接區(qū)分開來最好。現(xiàn)實(shí)情況是，這一切都取決于具體情況。大量的優(yōu)勢清單并不能使一個(gè)優(yōu)于另一個(gè)。

建議在做出有關(guān)應(yīng)用程序的前端和后端的拆分或連接的任何決定之前，先考慮項(xiàng)目的傳入和輸出。

結(jié)論

前端和后端的加入和分離有一些優(yōu)點(diǎn)和缺點(diǎn)。考慮到目前的發(fā)展情況，可以選擇兩者中最好的。

開發(fā)框架前后端分離的好處是什么?文章來源地址http://www.zghlxwxcb.cn/news/detail-497697.html

到了這里，關(guān)于開發(fā)框架前后端分離的好處是什么的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！