前后端分離的作用，如何前后端分離，如何解耦？

大家好，在本文中我們一起來(lái)探討一下為什么要在軟件開(kāi)發(fā)中進(jìn)行前后端的分離，如何做到前后端分離，如何解耦。

簡(jiǎn)單地說(shuō)，就是要把復(fù)雜的問(wèn)題簡(jiǎn)單化，把一個(gè)從0到N的問(wèn)題轉(zhuǎn)化為N個(gè)0到1的問(wèn)題。另一個(gè)相近的說(shuō)法就是“解耦”。

舉個(gè)例子，我們接到一個(gè)客戶需求，要求寫(xiě)一個(gè)應(yīng)用，這個(gè)應(yīng)用中有頁(yè)面的切換，有對(duì)應(yīng)頁(yè)面的數(shù)據(jù)交互，數(shù)據(jù)的獲取，數(shù)據(jù)的計(jì)算，如果把這些功能放在一個(gè)單一的應(yīng)用中的話，從大局觀的角度來(lái)看，這個(gè)單一的應(yīng)用是比較復(fù)雜的。

為了降低這個(gè)復(fù)雜度，我們首先要做的就是前后端分開(kāi)，關(guān)于前后端的定義，大體來(lái)說(shuō)是這樣的：前端負(fù)責(zé)的內(nèi)容主要有頁(yè)面路徑管理，頁(yè)面對(duì)應(yīng)數(shù)據(jù)的顯示與管理等等；后端負(fù)責(zé)的內(nèi)容主要有數(shù)據(jù)的提供，數(shù)據(jù)的計(jì)算，安全性管理等等；前后端的通信一般通過(guò)HTTP請(qǐng)求來(lái)實(shí)現(xiàn)；當(dāng)然這里也有個(gè)例外情況，比如有一部分功能可能要求實(shí)時(shí)性，像類似聊天類的功能，共享文檔的功能，畫(huà)板分享的功能，多人協(xié)同操作的功能等等，需要通過(guò)socketio這樣的通信機(jī)制進(jìn)行。

再細(xì)分一下講，單一的程序框架模型會(huì)是MVC（Model-View-Controller）結(jié)構(gòu)的。前后端分離以后，后端會(huì)有Model/Entity-Repository/Service-Controller，前端會(huì)有View-Model-API調(diào)用。

看一下前端部分，View主要是指網(wǎng)頁(yè)的頁(yè)面，手機(jī)端的頁(yè)面（Android就是Activity，Layout和View等，?iOS就是View Controller和UIView等），如果使用跨平臺(tái)技術(shù)（如React Native, Flutter，Xamarin等）也離不開(kāi)上述的概念，大同小異。這部分的處理當(dāng)然離不開(kāi)數(shù)據(jù)Model和API調(diào)用。處理好這些以后前端的任務(wù)也就做好了。

再看一下后端部分，界面相關(guān)的處理已經(jīng)不再是后端的任務(wù)了，后端只需要通過(guò)API提供前端需要的數(shù)據(jù)就可以了。Controller就是用來(lái)定義這些API的，這一部分會(huì)分析或者計(jì)算出前端的輸入和輸出模型，具體處理方式有以下幾個(gè)因素考慮：請(qǐng)求的類型如GET，POST，?PUT，?DELTE，PATCH等；數(shù)據(jù)From Body，數(shù)據(jù)From Route，數(shù)據(jù)From Form等等；數(shù)據(jù)處理完成以后，一個(gè)是通過(guò)API返回，一個(gè)是更新數(shù)據(jù)源，這里的數(shù)據(jù)源可以是數(shù)據(jù)庫(kù)如SQL和NoSQL，可以是消息中間件如Kafka，也可以是數(shù)據(jù)緩沖服務(wù)器如Redis等等。通過(guò)上述的描述，我們可以看到后端的任務(wù)變得更加輕量級(jí)了，邏輯上也更加簡(jiǎn)單了。

所以，通過(guò)前后端的分離，我們把前端和后端的復(fù)雜度始終維持在可控的范圍內(nèi)。如果在軟件開(kāi)發(fā)中始終使用這種理念的話，我們會(huì)大大擴(kuò)展我們的軟件開(kāi)發(fā)效率和程序質(zhì)量。因?yàn)榻鉀Q一個(gè)N難度的問(wèn)題顯然要比解決N個(gè)1難度問(wèn)題要困難得多。對(duì)于一個(gè)N難度的問(wèn)題，我們將其分解為N個(gè)1難度的問(wèn)題之后，我們可以各個(gè)擊破，步步為營(yíng)，一步一個(gè)腳印，在工作中從容而且自信，因?yàn)槲覀兪冀K用最簡(jiǎn)單的方法去解決問(wèn)題。如果碰上復(fù)雜的問(wèn)題，就再將其分化為多個(gè)難度為1的問(wèn)題，以此類推。簡(jiǎn)單一些講，就是要保證我們?cè)诮鉀Q問(wèn)題的時(shí)候，不打無(wú)準(zhǔn)備之仗，始終腳踏實(shí)地，分而治之，避免把我們自己架到火爐上烤。

復(fù)雜度降低以后，整個(gè)項(xiàng)目的維護(hù)成本和擴(kuò)展成本都會(huì)非常的低。我們對(duì)項(xiàng)目開(kāi)發(fā)的駕馭能力也會(huì)提高很多。

再說(shuō)一個(gè)數(shù)據(jù)流向的問(wèn)題，這個(gè)主要發(fā)生在前端。?這部分的處理會(huì)直接關(guān)聯(lián)到前端程序設(shè)計(jì)的復(fù)雜度。在三大前端框架中有雙向數(shù)據(jù)流向和單向數(shù)據(jù)流向，其中React只支持單向數(shù)據(jù)流向。但是目前有了Hooks機(jī)制以后，你可以通過(guò)傳Setter和Getter兩個(gè)Reference來(lái)達(dá)到修改數(shù)據(jù)的目的。這種通過(guò)傳遞參數(shù)到其他Component的模式實(shí)際上增加了程序的復(fù)雜度，因?yàn)橐粚訉拥膫鬟f使得組件之間的耦合性增強(qiáng)了。

那么如何解決這個(gè)問(wèn)題呢？

在Angular中可以通過(guò)Service中定義Getter和Setter來(lái)解決這個(gè)問(wèn)題，每個(gè)需要操作這個(gè)數(shù)據(jù)的組件都可以依賴注入這個(gè)Service，有了這個(gè)Service，就可以很輕松的讀取和更新其中的數(shù)據(jù)了，對(duì)于數(shù)據(jù)的監(jiān)聽(tīng)，可以通過(guò)在Service定義一個(gè)Subject，監(jiān)聽(tīng)到數(shù)據(jù)變化以后，你可以更新界面，向服務(wù)器發(fā)送請(qǐng)求等等，這樣做，組件之間的耦合性就大大降低了。

再說(shuō)一下單向數(shù)據(jù)流向機(jī)制如Ngrx, VueX, Mux等等。單向數(shù)據(jù)流向機(jī)制在目前的前端開(kāi)發(fā)中使用很普遍，然而，實(shí)際上這種機(jī)制會(huì)增加程序的復(fù)雜度。這個(gè)主要是因?yàn)檫@種機(jī)制會(huì)在前端開(kāi)發(fā)層級(jí)中引入另外一套體系來(lái)維護(hù)數(shù)據(jù)的流向，假如我們對(duì)已有的業(yè)務(wù)定義為從0到1的實(shí)現(xiàn)，加上這個(gè)機(jī)制以后，就變成了0到1再加上另外一個(gè)0到1，變成了0到2的問(wèn)題。這就變復(fù)雜了。

前端只要做好如下的任務(wù)如頁(yè)面的切換，數(shù)據(jù)與后端的交互，數(shù)據(jù)模型與API的對(duì)應(yīng),?組件盡量的寫(xiě)成Self-Contained就可以了。

所以我不建議在前端中再額外的添加類似的數(shù)據(jù)流向機(jī)制了。

再談一下后端的分析。我們?cè)谡労蠖说臅r(shí)候，我們不太關(guān)心使用什么技術(shù)（Node JS，.net Core，SpringBoot，PHP, Python, Ruby On Rails等等），這是因?yàn)楹蠖说倪壿嬍乔逦模还苣阌媚欠N技術(shù)，程序的設(shè)計(jì)的層級(jí)是大同小異的。

后端的主要任務(wù)是API數(shù)據(jù)的提供。比如用戶相關(guān)的API，創(chuàng)建一個(gè)用戶，更新一個(gè)用戶，刪除一個(gè)用戶等等的操作都是在一個(gè)用戶Controller定義相關(guān)的API。對(duì)于Controller的添加，我建議要根據(jù)業(yè)務(wù)層來(lái)添加，不要在一個(gè)Controller中做太多的事情。比如我們可以添加Book Controller來(lái)處理Book相關(guān)的操作，訂單Controller來(lái)處理訂單相關(guān)的操作。

這樣做是為了把API設(shè)計(jì)變成線性的，平行的，各自Controller之間的耦合性降到最低，從而也就降低了復(fù)雜度。

進(jìn)一步說(shuō)，在實(shí)現(xiàn)的層級(jí)上，我們可以有Data Set對(duì)應(yīng)數(shù)據(jù)庫(kù)表格，Entity對(duì)應(yīng)數(shù)據(jù)表格記錄，Model對(duì)應(yīng)API數(shù)據(jù)模型，Service/Repository負(fù)責(zé)邏輯實(shí)現(xiàn)等等。

在后端技術(shù)選取中，數(shù)據(jù)庫(kù)相關(guān)的操作是一個(gè)不可逾越的門檻，有的框架使用類似EntityFramework的機(jī)制如.NetCore和PHP Laravel,?有的使用類似JPA Hibernate，Mybatis如Spring Boot，有的則直接使用JDBC SQL語(yǔ)句執(zhí)行的方式，有的結(jié)合Stored Procedure。在這個(gè)地方，按照程序復(fù)雜度排序的話，由低到高分別是EntityFrameWork

當(dāng)然，數(shù)據(jù)庫(kù)的設(shè)計(jì)，數(shù)據(jù)庫(kù)的升級(jí)Migration也都是關(guān)系到程序項(xiàng)目復(fù)雜度的因素。這個(gè)要結(jié)合具體的后端技術(shù)來(lái)談。?在本文中我們就不展開(kāi)了。

好了，本文我們主要探討了前后端分離的作用，如何進(jìn)行前后端分離，如何解耦，有不足之處，請(qǐng)不吝指正。

架構(gòu)設(shè)計(jì)

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。