本篇內(nèi)容主要講解“web前端與后端分離的架構(gòu)實例分析”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“web前端與后端分離的架構(gòu)實例分析”吧!

堅守“ 做人真誠 · 做事靠譜 · 口碑至上 · 高效敬業(yè) ”的價值觀，專業(yè)網(wǎng)站建設服務10余年為成都軟裝設計小微創(chuàng)業(yè)公司專業(yè)提供企業(yè)網(wǎng)站建設營銷網(wǎng)站建設商城網(wǎng)站建設手機網(wǎng)站建設小程序網(wǎng)站建設網(wǎng)站改版，從內(nèi)容策劃、視覺設計、底層架構(gòu)、網(wǎng)頁布局、功能開發(fā)迭代于一體的高端網(wǎng)站建設服務。

一、關于前端的 dataProvider

簡單點說，就是一個給界面調(diào)用的數(shù)據(jù)訪問層，很多人都人這樣的疑問，在這里加一個數(shù)據(jù)訪問層，是不是多余？只要你做的前端，你都會碰到下面這些問題：

1、一個產(chǎn)品或者項目，前端與后端是同時進行了，這時候，根本沒有后端的接口，甚至可以說，連個接口的定義都沒有。作為前端開發(fā)人員，你如何去開展自己的工作？

2、作為前端開發(fā)人員，你有沒有碰到，因為后端的接口掛掉，導致你的工作沒法繼續(xù)做下去的情形？

3、作為前端開發(fā)人員，往往免不了要和第三方的接口進行對接，你有沒有碰到過，和你做對接的人員，突然因為項目緊，被抽走了，留給你的只有一堆需要傳N個參數(shù)，傳了后接著出“對象為空”的異常呢？你根本不知道哪里參數(shù)傳錯了。面對這些接口，你除了破口大罵，得不到任何幫助。

4、作為前端開發(fā)人員，你有沒有試過，你向后端的開發(fā)組，要一個接口，他們需要討論個幾天，然后再花幾天才能給你，給你之后，還不能用，又得再花幾天時間調(diào)試呢？

如果你向我一樣，都曾經(jīng)都碰過這些問題，你就不會懷疑這個 dataProvider 存在的必要了，有了這個 dataProvider，可以***減少后端接口對前端開發(fā)的影響。下面是一個 dataProvider 的實例：

var dataProvider = (function () {      var fakeProvider = {         countries: new Countries()     };      var realProvider = {         countries: new JData.WebDataSource()     };      //下面的接口，根據(jù)情況二選一     return fakeProvider; //這個是假的 dataProvider，從本地讀     return realProvider; //這個是真正 dataProvider，從接口讀 })();

從上面可以看出來，這個 dataProvider 使用了工廠模式來創(chuàng)建，它有兩個實例，fakeProvider和realProvider，fakeProvider是用來提供一些模擬數(shù)據(jù)，而realProvider提供從接口讀取出來的數(shù)據(jù)。當沒有接口，或者接口掛掉，我們可以先從 fakeProvider 來讀取數(shù)據(jù)。等接口好了，切換到 realProvider 。

二、關于用戶界面輸入的驗證

1、數(shù)據(jù)的驗證。用戶在界面輸入數(shù)據(jù)后，接著調(diào)用 dataProvider 里的接口對數(shù)據(jù)進行處理，但是在向服務端提交之前，得先對數(shù)據(jù)進行驗證。那個這個驗證如何進行呢？dataProvider先從服務端獲實體的描述信息，這些描述包括但不限于：主外鍵、屬性的驗證信息（比如是否可空），當然，這個實體信息是可以緩存起來，以便重用的。然后 dataProvider 再根據(jù)這個描述信息來對數(shù)據(jù)進行驗證。

2、錯誤信息的顯示

當驗證到某一個屬性不合法，驗證信息的模塊就在頁面查找出對應輸入控件，它是怎么查找的呢？比如說，Contry 的 Name 輸入為空是不可以的。那它就先查找 id 為Coutry的元素，然后再Coutry元素下面再找id 或者 name 為 Name 的控件，如果找不到則直接彈窗顯示錯誤信息。例如：

三、關于后端使用 OData

1、作為后端開發(fā)人員，你有沒有碰到過這種前端開發(fā)人員，今天讓你加一個字段，好，加了，然后打包發(fā)布。明天又讓你加一個字段。后天突然又說，前兩天加的字段，不需要，你會不會有種想喊“操”的沖動？

2、作為后端開發(fā)員員，你有沒有碰到過這種前端開發(fā)人員，今天跟你說接口不夠用，要加個 GetUserByName 的方法，明天又說，還得加個 GetUserByEmail 的方法？然后，過了一段時間，你發(fā)現(xiàn)接口越來越多，維護的模塊越來越癰腫，并且這些接口，你只敢加，不敢刪除。因為，你根本不知道這些，有哪個不用的，你跑去問前端，他也回答不出來。所以一些接口哪怕是沒用的，也只能永遠系統(tǒng)里，直到它生命周期的結(jié)束。

如果你也碰到類似于我這種煩惱，使用 OData 也許是一個不錯的選擇，把查詢的權限都開發(fā)給前端的開發(fā)人員，他愛怎么查就怎么查，都由它去。

四、關于后端使用MVC

我們的系統(tǒng)，使用MVC都是用來處理從前端提交上來的數(shù)據(jù)的，使用它主要是開發(fā)人員都熟悉MVC，然后MVC再調(diào)用業(yè)務層代碼，同時，還需要處理:

1、對提交上來的數(shù)據(jù)進行驗證

2、處理系統(tǒng)的異常，包括對異常進行重新的包裝，再傳回到客戶端，以便于客戶端的處理。對異常的信息進行記錄。

五、數(shù)據(jù)訪問層

關于數(shù)據(jù)訪問層，在我們的系統(tǒng)里實際是一個 ORM 的包裝器（ORM Wrapper），你在對 ORM 裹上一層外衣。目的在于：

1、對數(shù)據(jù)進行攔截。例如：有些數(shù)據(jù)，只對某個角色的開發(fā)。數(shù)據(jù)訪問層需要對根據(jù)過濾條件，然后再結(jié)合查詢條件，重新生成SQL。

2、對數(shù)據(jù)假刪除的處理。見過很多系統(tǒng)，都是把刪除放到業(yè)務層來進行的，其實這是不適合的，從業(yè)務的角度來說，關心的是刪除，在執(zhí)行刪除后，這條數(shù)據(jù)從我眼前消失就可以了。至真刪除還是假刪除，這與我無關。數(shù)據(jù)訪問層，要做的就是這工作，它可以數(shù)據(jù)在真刪除與假刪除之間進行切換，只要配置一下，就可以把真刪除變成假刪除（其實就是把Delete操作變成Update操作），使得進行業(yè)務開發(fā)人員，不用再關心數(shù)據(jù)的真假刪除。

3、對數(shù)據(jù)進行跟蹤、備份。你肯定碰到過這么一種需要，需要記下來，每一次的更新操作的時間，以及更新了些什么內(nèi)容。對于刪除的數(shù)據(jù)，能夠把它還原回來。數(shù)據(jù)訪問層，通過對 ORM進行包裝，完全可以記錄下每一次更新、刪除這些操作，然后記錄下來即可。當然，這些需求利用數(shù)據(jù)提供的功能也是可以實現(xiàn)的，不在討論的范圍內(nèi)。

到此，相信大家對“web前端與后端分離的架構(gòu)實例分析”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關內(nèi)容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！