一個前端與後端分離的架構例項
最近在為新系統的架構進行選型,覺得前後分離是個選擇的方向,當然也還有很多待解決問題。這篇很有幫助,原文如下:
看了《系統架構:Web應用架構的新趨勢---前端和後端分離的一點想法》 這篇文章,對前端與後端的分離非常認同,這樣做對於系統的維護是有相當大的好處的。正好自己也設計了一個這樣的系統,於是把它拿出來,和大家討論一下。這個架構,與其說是想出來,還不如說是我做系統總結出來的最佳實踐。
我們做的系統,前端的頁面基本都是使用 JavaScript 的富戶端頁面,主要應用的框架用,jquery、jquery ui、knockout js、Durandal、另外,還有自己封裝的一些 UI 元件,後端的主要採用到的技術有 OData、MVC、Linq to SQL 以及自己寫的一個許可權管理元件,資料庫採用的是 SQL Server 2005。
下面向大家介紹一下各模組的功能以及其劃分的目的,我們先從使用者介面看起吧。
一、關於前端的 dataProvider
簡單點說,就是一個給介面呼叫的資料訪問層,很多人都人這樣的疑問,在這裡加一個數據訪問層,是不是多餘?只要你做的前端,你都會碰到下面這些問題:
1、一個產品或者專案,前端與後端是同時進行了,這時候,根本沒有後端的介面,甚至可以說,連個介面的定義都沒有。作為前端開發人員,你如何去開展自己的工作?
2、作為前端開發人員,你有沒有碰到,因為後端的介面掛掉,導致你的工作沒法繼續做下去的情形?
3、作為前端開發人員,往往免不了要和第三方的介面進行對接,你有沒有碰到過,和你做對接的人員,突然因為專案緊,被抽走了,留給你的只有一堆需要傳N個引數,傳了後接著出“物件為空”的異常呢?你根本不知道哪裡引數傳錯了。面對這些介面,你除了破口大罵,得不到任何幫助。
4、作為前端開發人員,你有沒有試過,你向後端的開發組,要一個介面,他們需要討論個幾天,然後再花幾天才能給你,給你之後,還不能用,又得再花幾天時間除錯呢?
如果你向我一樣,都曾經都碰過這些問題,你就不會懷疑這個 dataProvider 存在的必要了,有了這個 dataProvider,可以最大減少後端介面對前端開發的影響。下面是一個 dataProvider 的例項:
- var dataProvider = (function () {
- var fakeProvider = {
- countries: new Countries()
- };
- var realProvider = {
- countries: new JData.WebDataSource()
- };
- //下面的介面,根據情況二選一
- return fakeProvider; //這個是假的 dataProvider,從本地讀
- return realProvider; //這個是真正 dataProvider,從介面讀
- })();
從上面可以看出來,這個 dataProvider 使用了工廠模式來建立,它有兩個例項,fakeProvider和realProvider,fakeProvider是用來提供一些模擬資料,而realProvider提供從介面讀取出來的資料。當沒有介面,或者介面掛掉,我們可以先從 fakeProvider 來讀取資料。等介面好了,切換到 realProvider 。
二、關於使用者介面輸入的驗證
1、資料的驗證。使用者在介面輸入資料後,接著呼叫 dataProvider 裡的介面對資料進行處理,但是在向服務端提交之前,得先對資料進行驗證。那個這個驗證如何進行呢?dataProvider先從服務端獲實體的描述資訊,這些描述包括但不限於:主外來鍵、屬性的驗證資訊(比如是否可空),當然,這個實體資訊是可以快取起來,以便重用的。然後 dataProvider 再根據這個描述資訊來對資料進行驗證。
2、錯誤資訊的顯示
當驗證到某一個屬性不合法,驗證資訊的模組就在頁面查找出對應輸入控制元件,它是怎麼查詢的呢?比如說,Contry 的 Name 輸入為空是不可以的。那它就先查詢 id 為Coutry的元素,然後再Coutry元素下面再找id 或者 name 為 Name 的控制元件,如果找不到則直接彈窗顯示錯誤資訊。例如:
- <formid="Country">
- <inputname="Name"/>
- </form>
三、關於後端使用 OData
1、作為後端開發人員,你有沒有碰到過這種前端開發人員,今天讓你加一個欄位,好,加了,然後打包釋出。明天又讓你加一個欄位。後天突然又說,前兩天加的欄位,不需要,你會不會有種想喊“操”的衝動?
2、作為後端開發員員,你有沒有碰到過這種前端開發人員,今天跟你說介面不夠用,要加個 GetUserByName 的方法,明天又說,還得加個 GetUserByEmail 的方法?然後,過了一段時間,你發現介面越來越多,維護的模組越來越癰腫,並且這些介面,你只敢加,不敢刪除。因為,你根本不知道這些,有哪個不用的,你跑去問前端,他也回答不出來。所以一些介面哪怕是沒用的,也只能永遠系統裡,直到它生命週期的結束。
如果你也碰到類似於我這種煩惱,使用 OData 也許是一個不錯的選擇,把查詢的許可權都開發給前端的開發人員,他愛怎麼查就怎麼查,都由它去。
四、關於後端使用MVC
我們的系統,使用MVC都是用來處理從前端提交上來的資料的,使用它主要是開發人員都熟悉MVC,然後MVC再呼叫業務層程式碼,同時,還需要處理:
1、對提交上來的資料進行驗證
2、處理系統的異常,包括對異常進行重新的包裝,再傳回到客戶端,以便於客戶端的處理。對異常的資訊進行記錄。
五、資料訪問層
關於資料訪問層,在我們的系統裡實際是一個 ORM 的包裝器(ORM Wrapper),你在對 ORM 裹上一層外衣。目的在於:
1、對資料進行攔截。例如:有些資料,只對某個角色的開發。資料訪問層需要對根據過濾條件,然後再結合查詢條件,重新生成SQL。
2、對資料假刪除的處理。見過很多系統,都是把刪除放到業務層來進行的,其實這是不適合的,從業務的角度來說,關心的是刪除,在執行刪除後,這條資料從我眼前消失就可以了。至真刪除還是假刪除,這與我無關。資料訪問層,要做的就是這工作,它可以資料在真刪除與假刪除之間進行切換,只要配置一下,就可以把真刪除變成假刪除(其實就是把Delete操作變成Update操作),使得進行業務開發人員,不用再關心資料的真假刪除。
3、對資料進行跟蹤、備份。你肯定碰到過這麼一種需要,需要記下來,每一次的更新操作的時間,以及更新了些什麼內容。對於刪除的資料,能夠把它還原回來。資料訪問層,通過對 ORM進行包裝,完全可以記錄下每一次更新、刪除這些操作,然後記錄下來即可。當然,這些需求利用資料提供的功能也是可以實現的,不在討論的範圍內。