自從前幾天寫了篇前端與後端分離的架構文章,總覺得有點意猶未盡的感覺,於是乎準備把寫成一個系統。準備逐漸深入地給大家去展現這個系統的架構。不過,我會寫得比較隨意,基本上想到什麼就寫什麼,不會有很嚴謹的邏輯關係。
這個系統,是我現在正在開發的一個系統的架構,可不是什麼理論或者拍腦袋想出來的。事實上,這個架構我思考了差不多一年了,還在上一家公司工作的時候,這個架構就在我的頭腦中醞釀了,只可惜一直沒有機會讓我去做,很感謝現在的老闆,給我這麼一個機會,讓我把它變為現實。
我們再來重溫一下我所負責開發的系統的架構:
前段架構
在這個圖裡面,大家可以看得到,前端部份,是通個一個資料訪問層去訪問服務端的資料的,可以簡單點說,是把遠端的資料訪問封裝在一個類裡。為什麼要這麼做呢?
我的設計理念裡,後端為前端去提供服務,而前端則去消費這些服務。但是,為前端提供服務的,不僅包括我們現在所開發的後端,而且還會有第三方提供的服務。舉一個例子來說:
我們開發的系統,要提供給某個商家去使用,這個商家,已經有現成的會員系統,它包括充值功能,並且這個系統也執行良好。這個商家並不願意拋棄現有的系統,而使用我們提供的會員系統,他只要我們基於產品銷售這個模組,當會員在網上下單的時候,我們的系統是要從商家提供的會員系統里扣除他的消費金額的。對於這種情況,我期待的是,我們需要做的只是替換掉資料訪問層中的某個模組即可。所以你會看到,我們的系統是把資料訪問部份獨立了出來,但是實際上,這個資料訪問層,還會包括若干個模組。
架構的複雜,是為了應對複雜的變化,如果你開發專案,只是在公司內部使用的,當然可以不去考慮這些。但是如果說要作為一個通用的產品,那就不得不去面對各種複雜的變化,尤其是系統整合這一塊。
資料跟蹤
什麼叫資料跟蹤呢?就是記錄下每一次資料的變化,比如說,使用者每一次對資料的刪除、修改、插入操作,都要記錄下來。我個人是很討厭資料的假刪除的,特別是到處都充斥著“where delete = true”,"update xxx set delete = true" 之類的程式碼。這種程式碼與業務是沒有任何關係,但是卻放在業務層裡,我認為是非常的不合理的。處理辦法兩種:
1、放在資料訪問層,通過 ORM 去處理,只需要通過配置,就可以把刪除操作變為更新操作。當然,業務層的程式碼,還是按刪除來處理。
2、使用的是真刪除,但是對刪除的資料進行記錄。由於把刪除的資料記錄了來,當然也可以把它還原了。
那如何去實現它呢?如果你使用的是 Linq to SQL,大家可以看我之前寫的《Linq to SQL (ALinq) 也來AOP —— ALinq Inject 部落格園首發》 ,它會告訴如何把刪除、更新、插入操作攔截下。
使用工廠模式建立實體
你的程式碼裡是否到處充斥著類似下面的這種程式碼呢?
var obj = new Account(); obj.ID = Guid.NewGuid(); obj.CreateDateTime = DateTime.Now;
當然,可以通過程式碼生成來解決。但是如果使用的是 Linq to SQL,就沒有那麼好辦了。我使用的是另外一種辦法,使用工廠模式來建立實體。例如:
public T CreateEntity<T>() where T : class, new() { var entity = new T() as dynamic; entity.ID = Guid.NewGuid(); entity.CreateDateTime = DateTime.Now; var applicationIdProperty = typeof(T).GetProperty("ApplicationId"); if (applicationIdProperty != null) entity.ApplicationId = this.ApplicationId; return entity; }
好了,這次就先聊到這裡,我很希望有更多的人加入我們的團隊,一起去完成這個架構。
招聘開發人員:懂 JQuery、JQuery UI、JQuery Validate、Knockout JS 等JS 框架,略懂 Linq to SQL,能閱讀文件,根據文件示例寫程式碼。(歡迎勤奮好學的畢業生)
1、側重前端開發,如果有能力,也可以從事後端開發。
2、工作努力認真,對自己負責,也對客戶負責。
加入我們團隊,在我的指導下,只要你肯努力,絕對能夠得很快的成長,相信我。^_^
有興趣的朋友可以加我 QQ 私聊。
地點:上海市閘北區
網站:http://www.vknew.com/index.html