前端與後端分離的架構實例（一）

看了《系統架構：Web應用架構的新趨勢---前端和後端分離的一點想法》 這篇文章，對前端與後端的分離很是認同，這樣作對於系統的維護是有至關大的好處的。正好本身也設計了一個這樣的系統，因而把它拿出來，和你們討論一下。這個架構，與其說是想出來，還不如說是我作系統總結出來的最佳實踐。

咱們作的系統，前端的頁面基本都是使用 JavaScript 的富戶端頁面，主要應用的框架用，jquery、jquery ui、knockout js、Durandal、另外，還有本身封裝的一些 UI 組件，後端的主要採用到的技術有 OData、MVC、Linq to SQL 以及本身寫的一個權限管理組件，數據庫採用的是 SQL Server 2005。

下面向你們介紹一下各模塊的功能以及其劃分的目的，咱們先從用戶界面看起吧

1、關於前端的 dataProvider

簡單點說，就是一個給界面調用的數據訪問層，不少人都人這樣的疑問，在這裏加一個數據訪問層，是否是多餘？只要你作的前端，你都會碰到下面這些問題：

一、一個產品或者項目，前端與後端是同時進行了，這時候，根本沒有後端的接口，甚至能夠說，連個接口的定義都沒有。做爲前端開發人員，你如何去開展本身的工做？

二、做爲前端開發人員，你有沒有碰到，由於後端的接口掛掉，致使你的工做無法繼續作下去的情形？

三、做爲前端開發人員，每每免不了要和第三方的接口進行對接，你有沒有碰到過，和你作對接的人員，忽然由於項目緊，被抽走了，留給你的只有一堆須要傳N個參數，傳了後接着出「對象爲空」的異常呢？你根本不知道哪裏參數傳錯了。面對這些接口，你除了破口大罵，得不到任何幫助。

四、做爲前端開發人員，你有沒有試過，你向後端的開發組，要一個接口，他們須要討論個幾天，而後再花幾天才能給你，給你以後，還不能用，又得再花幾天時間調試呢？

若是你向我同樣，都曾經都碰過這些問題，你就不會懷疑這個 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 。

2、關於用戶界面輸入的驗證

一、數據的驗證。用戶在界面輸入數據後，接着調用 dataProvider 裏的接口對數據進行處理，可是在向服務端提交以前，得先對數據進行驗證。那個這個驗證如何進行呢？dataProvider先從服務端獲實體的描述信息，這些描述包括但不限於：主外鍵、屬性的驗證信息（好比是否可空），固然，這個實體信息是能夠緩存起來，以便重用的。而後 dataProvider 再根據這個描述信息來對數據進行驗證。

二、錯誤信息的顯示

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

<form id="Country">
       <input name="Name"/>
</form>

 

3、關於後端使用 OData

一、做爲後端開發人員，你有沒有碰到過這種前端開發人員，今天讓你加一個字段，好，加了，而後打包發佈。明天又讓你加一個字段。後天忽然又說，前兩天加的字段，不須要，你會不會有種想喊「操」的衝動？

二、做爲後端開發員員，你有沒有碰到過這種前端開發人員，今天跟你說接口不夠用，要加個 GetUserByName 的方法，明天又說，還得加個 GetUserByEmail 的方法？而後，過了一段時間，你發現接口愈來愈多，維護的模塊愈來愈癰腫，而且這些接口，你只敢加，不敢刪除。由於，你根本不知道這些，有哪一個不用的，你跑去問前端，他也回答不出來。因此一些接口哪怕是沒用的，也只能永遠系統裏，直到它生命週期的結束。

若是你也碰到相似於我這種煩惱，使用 OData 也許是一個不錯的選擇，把查詢的權限都開發給前端的開發人員，他愛怎麼查就怎麼查，都由它去。

4、關於後端使用MVC

咱們的系統，使用MVC都是用來處理從前端提交上來的數據的，使用它主要是開發人員都熟悉MVC，而後MVC再調用業務層代碼，同時，還須要處理:

一、對提交上來的數據進行驗證

二、處理系統的異常，包括對異常進行從新的包裝，再傳回到客戶端，以便於客戶端的處理。對異常的信息進行記錄。

5、數據訪問層

 關於數據訪問層，在咱們的系統裏實際是一個 ORM 的包裝器（ORM Wrapper），你在對 ORM 裹上一層外衣。目的在於：

一、對數據進行攔截。例如：有些數據，只對某個角色的開發。數據訪問層須要對根據過濾條件，而後再結合查詢條件，從新生成SQL。

二、對數據假刪除的處理。見過不少系統，都是把刪除放到業務層來進行的，其實這是不適合的，從業務的角度來講，關心的是刪除，在執行刪除後，這條數據從我眼前消失就能夠了。至真刪除仍是假刪除，這與我無關。數據訪問層，要作的就是這工做，它能夠數據在真刪除與假刪除之間進行切換，只要配置一下，就能夠把真刪除變成假刪除（其實就是把Delete操做變成Update操做），使得進行業務開發人員，不用再關心數據的真假刪除。

三、對數據進行跟蹤、備份。你確定碰到過這麼一種須要，須要記下來，每一次的更新操做的時間，以及更新了些什麼內容。對於刪除的數據，可以把它還原回來。數據訪問層，經過對 ORM進行包裝，徹底能夠記錄下每一次更新、刪除這些操做，而後記錄下來便可。固然，這些需求利用數據提供的功能也是能夠實現的，不在討論的範圍內。

 

這篇文章到此結束，歡迎你們的板磚。

PS:過年的時候，我會把 ALinq 和 Visual Entity 更新到 2013，各位用戶就別催更了，最近實在是忙，抽不出時間更新呀。

 

 

公司招聘

初級程序員：懂 JQuery、JQuery UI、JQuery Validate、Knockout JS 等JS 框架，略懂 Linq to SQL，能閱讀文檔，根據文檔示例寫代碼

中級程序員：有閱讀上述框架的代碼，並根據項目作訂製開發

高級程序員：具體很強的編碼能力，能解決各類疑難雜症

牛人：能把設計模式、代碼玩弄於股掌之間

地點：上海市閘北區

網站：http://www.vknew.com/index.html

在找工做的朋友能夠私信我。