距離「ASP.NET MVC 專案分層架構」系列的第六篇到現在已經有兩年都沒有再開新篇,本來應該是要接著再寫第七篇,起初是因為沒有時間而一直延宕,但後來開始覺得我不曉得要如何寫接下來的內容,以致於這兩年多來都沒有任何的動作,一直到了今年 twMVC 的第一場研討會,才藉著這個機會將這個系列從第一篇到第七篇(只限定在研討會的 Part.7)給做個整理與說明。
距離「ASP.NET MVC 專案分層架構」系列的第六篇到現在已經有兩年都沒有再開新篇,本來應該是要接著再寫第七篇,起初是因為沒有時間而一直延宕,但後來開始覺得我不曉得要如何寫接下來的內容,以致於這兩年多來都沒有任何的動作,一直到了今年 twMVC 的第一場研討會,才藉著這個機會將這個系列從第一篇到第七篇(只限定在研討會的 Part.7)給做個整理與說明。
有網友在「ASP.NET MVC 專案分層架構 Part.6 - DI/IoC 使用 Unity.MVC」這篇文章提出了一個問題:
一開始我還以為是我的 DbContext 是不是有做了什麼特殊設定還是忘了做什麼設定才會出現這樣的情況,然後我把範例程式給找出來,按照網友所提出的情境做操作,結果還真的如他所說的,當我在執行的網頁上做新刪修查時都不會有問題,資料也會同步,但如果直接對資料做修改後,網頁上面的資料並不會跟著改變,在仔細看過原本的程式之後才恍然大悟,我犯了一個嚴重的低級錯誤才會導致這種資料不一致的狀況,這一篇就是來說明要如何改正這個問題。
有關這個錯誤的文章如下:
「ASP.NET MVC 專案分層架構 Part.6 - DI/IoC 使用 Unity.MVC」「ASP.NET MVC 4 使用 Unity bootstrapper for ASP.NET MVC」
可以按照此篇文章的作法來修正錯誤。
從去年 (2012) 的十月開始一直到今年 (2013) 四月之間,我一共寫了六篇有關專案分層架構的文章,從一開始的怎麼在單一的 MVC 網站專案去抽出資料存取的部分為 Repository,接著再把 Repository 從網站專案分出來,自成一個類別庫專案,再來就是把屬於商業邏輯的部份抽出來成為 Service,然後就是如何使用 IoC Container。
很多人對於這個系列有很大的興趣,但也有很多人對於這些文章的內容有很多的疑問與困惑,從文章下面的留言回覆就可以感受到,甚至於在 twMVC 的每週四固定聚會時都會當面詢問有關這系列文章的相關問題。
有鑑於目前對於有這麼多問題的情況下,在進入此系列的下一篇文章前,實在需要來個中場休息時間(這個中場休息時間還真久,距離上一篇的系列文章已經快要三個月了),藉由這一篇文章來做個補充說明與看這個系列文章的一些建議。
隔了好長一段時間沒有接續這個系列的文章,現在直接從 DI/IoC 來繼續專案分層架構的主題,有關在專案裡實作 DI/IoC 的 Framework 有相當多,例如:Autofac, Castle Windsor, StructureMap, Ninject, Simple Injector, Enterprise Library Unity Application Block 等,其實還有很多的 Framework 可以使用,但這邊並不是探討哪一種 Framework 的優劣,這些 DI/IoC Framework 都相當不錯而且也有很多人使用,在網路上也可以找到豐富的文件以及參考文章,而這篇文章則是使用「Unity.MVC4」。
DI:Dependency Injection 依賴注入.
IoC:Inversion of Control 控制反轉.
P.S.
其他 DI/IoC Framework 的使用則會另開文章來做介紹,就不是隸屬於「分層架構」的分類中。
這一篇距離上一篇「ASP.NET MVC 專案分層架構 Part.4 - 抽出 Model 層並建立為類別庫專案」相隔了好一段時間,除了說工作比較忙碌而沒有時間外,其實主要是為了這個系列的章節順序傷腦筋,因為想要先說其他的部份,但是如果不先說 Service 層的話,後續的章節也不見得會比較好寫,但寫了 Service 層會把之前的一些東西給推翻掉,怕會引起太多的反彈,內容就這樣反反覆覆,文章也寫得斷斷續續,最後還是決定先說明 Service 層。
看這一篇之前一定要先看過「分層架構」的 Part.1 ~ Part.4 這四篇文章。
經過了前面三篇的過程,我們使用了 Repository Pattern 把有關資料存取的部分從 Controllers 程式中抽離出來,而現在我們接下來要做的是把專案中有關資料存取的部分給抽出來,另外建立一個 Project 來放置這些抽離出來的資料存取層。
把 Model 層從 Web 專案中抽離出來,這表示 Web 專案只關注於資料呈現以及系統控制流程的部份,凡是要跟資料打交道的存取操作就不會出現在 Web 專案中,讓兩個專案有各自的職責與關注的事物。
離上一篇「ASP.NET MVC 專案分層架構 Part.2 抽出 Repository 裡相同的部份」的發佈也隔了一段時間,我們繼續這一個主題,上一篇的內容是把原本分成個別 Repository 中的相同部分給抽出來,並且應用泛行的特性而另外建立一個 GenericRepository 來處理這些基本的資料存取操作,但非每一個類別的資料操作都是相同的,不是建立一個 GenericRepository 就可以滿足所有的需求,當各個類別有不同的資料存取需求時,應該怎麼做呢?
2014-12-02 補充說明:
這一系列的文章並不適合初階及中階的開發人員,如果你是程式開發的初學者或是 ASP.NET MVC 初學者,甚至是開發經驗少於兩年的開發人員,請馬上離開此篇文章。
經過「ASP.NET MVC 專案分層架構 Part.1 初學者的起手式」這一篇之後,雖不能說對於分層架構有很詳細的理解,但至少對於分層架構有了初步的概念與想法,上一篇我們已經做到了把各個 Model 的資料存取抽離出來並另外建立個別的 Repository,而這也只是剛開始而已,上一篇文章有人反應篇幅過長,以致無法耗費太多時間將整篇文章看完,所以這一篇就不再長篇大論,只專注於一個主題上,接下來要說的是把個別 Repository 中相同的部份給抽離出來,讓我們關注於這一點吧!
2014-12-02 補充說明:
雖然標題包含「初學者」但不表示這是給連 ASP.NET MVC 初學者甚至是程式初學者所看的,對象為已經具有一定程式開發基礎但是對於簡單的分層架構不太瞭解以及沒有概念的開發人員。
上星期(10/13 六)是 twMVC 第五場研討「活動宣傳 - 2012-10-13 twMVC 第五次研討會 … 雲端、專案系統架構」,上半場的主題是由 Bibby 所帶來的「ASP.NET MVC 之實戰架構探討」,有關於專案架構的資訊是每一次 twMVC 研討會後問卷上一定會有人提到想要聽的主題,所以這一次就由 Bibby 來說明,Bibby 在這一場的內容包含了專案架構相關的內容,而會後的問卷結果看來,大家的接受度都相當地高,不過也有些朋友反應說要看一點實作面的內容。
分層開發架構並不是 ASP.NET MVC 獨有的,任何的專案開發不管使用什麼樣的技術都應該要做好專案架構的分層,不管是同一個專案中的分層處理或是不同職責方法的獨立專案分層架構,專案分層架構其目的就是為了要職責確立、關注點分離,讓不同的方法或類別去做該做的事情而且只專注於這些方法、類別的職責上。
接下來的幾篇文章將會以初學者對象,將大雜匯式的專案開發內容逐步的改變,讓專案改為分層架構,所以對於進階開發人員,或是已經會分層架構的朋友就可以跳過這幾篇文章。
而我這邊所講述的分層架構方法也不是絕對或標準、唯一的方法,每個人、每個團隊對於程式的寫法、架構的區分都個有不同,對於架構的見解與實作的方式也有不同,所以我所說明的內容也只是將我的部份見解給寫出來,就如同標題一樣,對象是「初學者」。