開篇一言
任何東西都不是一蹴而就，它往往有一個衍變的過程，把握事情的規律，會讓我們更加深刻地理解它。而本文也是是順着這個思路過來的。
第4代架構代碼結構簡圖
如果你沒有看過該系列的第一篇文章，那么你可能會對這篇文章有些困惑，所以建議讀者先查看第一篇文章（【大型網站開發系列第一篇】——網站結構層次）。
從上面圖片看來，一切都是那么的熟悉，跟大家在開發項目的過程中項目的設定基本一致。你可以把它說成是三層架構、多層架構，隨便你怎么給它取名。但是第4代架構代碼不僅僅是這樣，這里只是一個最最基本的代碼結構，實際開發中，我們還有Windows Serivces服務、Remoting Services服務，以及很多在Microsoft給我們提供的模板之上開發的各種服務。
詳細代碼結構圖（最重要、也是最容易擴展的一個項目代碼）
Jiangzhichao.Demo.DAC
做過數據庫操作代碼底層封裝的人，應該差不多都知道這些類的含義，以及它們之間的一些關系。
抽象類DataHelper，是對各種數據庫操作代碼的一個抽象，提取出公共的代碼邏輯，定義一些公共的代碼接口讓子類去實現，基本上做到了數據庫和應用之間的解耦。
使用介紹
使用Jiangzhichao.Demo.DAC還是比較簡單的，只要實例化一個DataHelper子類出來，然后使用該子類的實例進行數據庫操作。這一步的操作我封裝在了Jiangzhichao.Demo.DataAccess項目的BaseDataAccess類里面，只需要傳入一個連接字符串和數據庫類型（這個可以放在配置文件中），然后進行業務開發就OK了。
第5代架構的衍變成型
從上面代碼結構簡圖可以看出，業務開發人員，只需要操作除Jiangzhichao.Demo.DAC項目以外的項目，業務開發人員不需要去了解Jiangzhichao.Demo.DAC里面對數據庫操作的封裝，唯一需要去了解的就是怎么去跟DBA溝通，讓DBA提供符合業務需要的數據接口（sql語句、存儲過程、方法）。
那么這就給底層開發人員一個很好的機會，專心研究底層架構，Jiangzhichao.Demo.DAC項目把數據和業務做了分離，底層開發人員在DAC這個項目中，只要保證對外的接口不變，內部的封裝就可以隨意改動，對業務開發人員一點影響都沒有，這做到了兩不誤，業務開發人員專心業務，底層開發人員專心底層封裝，並行開發，對整個項目的推進是個很大的幫助。
所以出現了第5代架構。第5代架構中，數據訪問層就可以在目前DAC的基礎上進行擴展，引入面向服務開發的概念，所有的數據都是以服務的方式提供給業務開發人員。那這個服務會是用什么方式提供呢？也許是WebServices，也許是Remoting，也許是WCF，還有可能是我們自己封裝的XX框架，你還可以把目前熱炒的分布式、海量存儲等XX東西給弄進來。
本篇結語
下一篇是想寫第5代架構原理的，處於自己對該架構的理解還不是很深，不敢輕易寫出來，半個月后，等我對該架構思路理清楚后再寫吧。所以下一篇，將是對該篇中提到的9個項目進行仔細講解。
本篇Demo代碼下載（未測試版）（請猛力點擊，哈哈）
請關注后續文章。
