層次體系就是利用分層的方式來處理復雜的功能，層次系統(tǒng)要求上層子系統(tǒng)可以使用下層子系統(tǒng)的功能，而下層子系統(tǒng)不能夠使用上層子系統(tǒng)的功能。一般下層每個程序接口執(zhí)行當前的一個簡單的功能，而上層通過調(diào)用不同的下層程序，并按不同的順序來執(zhí)行這些下層程序，層次體系就是以這種方式來完成多個復雜的業(yè)務功能的。
客戶機/服務器結(jié)構(gòu)簡稱C/S結(jié)構(gòu)或稱兩層結(jié)構(gòu)。
客戶/服務器應用模式的特點是大都基于“肥客戶機”結(jié)構(gòu)下的兩層結(jié)構(gòu)應用軟件?？蛻舳塑浖话阌蓱贸绦蚣跋鄳臄?shù)據(jù)庫連接程序組成。服務器端軟件一般是某種數(shù)據(jù)庫系統(tǒng)。
三層次客戶機/服務器結(jié)構(gòu)和瀏覽器/服務器結(jié)構(gòu)的數(shù)據(jù)庫服務器管理端由于客戶端連接數(shù)少，也常采用C/S結(jié)構(gòu)。
“瀏覽器/服務器”結(jié)構(gòu)是當前非常流行的客戶機/服務器結(jié)構(gòu)，簡稱B/S結(jié)構(gòu)。
這種結(jié)構(gòu)最大的優(yōu)點是：客戶機統(tǒng)一采用瀏覽器，這不僅讓用戶使用方便，而且使得客戶機不存在及安裝維護的問題。
三層次客戶機/服務器結(jié)構(gòu)是在常規(guī)客戶機/服務器結(jié)構(gòu)上提出的，系統(tǒng)在客戶機和數(shù)據(jù)庫服務器間添加一個應用服務器。
（1）所支持系統(tǒng)體系結(jié)構(gòu)的擴展
以上介紹的體系結(jié)構(gòu)，都是較為流行的，應用的范圍比較廣，我們的框架必須要支持不同的系統(tǒng)結(jié)構(gòu)，以滿足不同系統(tǒng)的要求，這里既包括業(yè)務的要求，也包括項目成本的要求以及其他。
當前公司所使用的框架可以支持三層客戶機/服務器結(jié)構(gòu)項目的開發(fā)，如果用來開發(fā)同是Windows應用并且要求快速的客戶機/服務器結(jié)構(gòu)的項目，框架將會變得臃腫不堪，那么框架的優(yōu)勢不能完全體現(xiàn)，而且還會造成部署和維護的困難。
開發(fā)框架的目的是提高項目的開發(fā)效率，所以為了適應不同體系結(jié)構(gòu)和進度要求的項目，需要有相對應的框架支持開發(fā)。比如要求快速并且可以選取客戶端/服務器體系結(jié)構(gòu)相對小型的項目，成本低，而且系統(tǒng)使用范圍也只是局域網(wǎng)，那么此系統(tǒng)的體系結(jié)構(gòu)可以采用支持客戶機/服務器的框架；如果項目屬于分布式的應用，使用三層次客戶機/服務器體系結(jié)構(gòu)，那么可以使用支持三層次客戶機/服務器結(jié)構(gòu)的框架等。
根據(jù)現(xiàn)有常用的體系結(jié)構(gòu)，至少有對應的三套框架：針對客戶機/服務器結(jié)構(gòu)的框架、三層次客戶機/服務器結(jié)構(gòu)的框架以及瀏覽器/服務器結(jié)構(gòu)的框架。（并不是說要有三套獨立的框架代碼，三套框架共有的組件可以復用，比如數(shù)據(jù)訪問層，比如通用接口等）
（2）技術(shù)的擴展
簡單一點，就拿層層之間通信來說吧?，F(xiàn)在的框架是使用Remoting技術(shù)實現(xiàn)客戶端與服務端之間的通信，我們肯定Remoting技術(shù)的優(yōu)點的同時，也要看清Remoting技術(shù)的缺點。 鑒于WebService的跨平臺的優(yōu)點，實現(xiàn)與不同平臺系統(tǒng)之間的交互，完全可以將框架之間的通信技術(shù)通過WebService實現(xiàn)，使框架不僅可以滿足了局域網(wǎng)的快速通信的要求（Remoting）,也可以滿足跨平臺的通信的要求(WebService)。
現(xiàn)在.Net 3.0提供的四個功能組件中，其中一個新的功能組是Windows Communication Foundation（WCF），有了WCF，開發(fā)人員不必再像從前一樣，處理每一類通信都要使用到不同的應用程序編程接口技術(shù)，使得通信應用變得簡單。因此，我們的框架也應該實現(xiàn)基于Windows Communication Foundation技術(shù)的通信，而不單純的使用Remoting。
技術(shù)的擴展，不僅包括上面所說的，以前我們沒有使用過的技術(shù)，或者是微軟最新提供了新技術(shù)，我們都可以考慮是否用于我們的框架，只要這樣的技術(shù)有優(yōu)勢，并符合我們業(yè)務的要求。
（1） 我們所做的工作不能以.Net或者Java平臺來區(qū)分，不能說使用.Net，就拒絕Java。簡單一點，它們都只是工具，我們應該更多的去關(guān)注在它們之上并且是想通的思想。
舉個例子，企業(yè)級應用的開發(fā)首選是J2EE，針對J2EE的表示層、邏輯層和數(shù)據(jù)持久層都有很多免費并且應用成熟的框架，而現(xiàn)在基于.Net的還沒有這樣具有影響力、成熟的框架。我們不是說要用J2EE的框架，至少我們應該有意識的去了解它們，了解它們的工作原理，了解它們的設計思想，了解它們的應用范圍，了解它們的優(yōu)缺點等，然后將這些總結(jié)運用到.Net平臺。有巨人的肩膀給你支撐，難道就因為它不是黃皮膚，我們就強烈地拒絕？
（2） 不論是在.Net平臺還是Java平臺，我們所要做的不僅僅只是局限于將現(xiàn)在的框架在不同的平臺上實現(xiàn)（相當于將框架從.Net平臺轉(zhuǎn)換為Java平臺），這樣的工作沒有太大的意義，因為我們所做的只是在功能實現(xiàn)上進行修修補補，框架始終停留在初始水平，進步可能只局限于技術(shù)的實現(xiàn)或者算法的優(yōu)化，這樣的做法將會限制框架的發(fā)展。極端一點，就像一個人的思想認識停留在遠古，顯然無法滿足社會進步的要求。
對框架的具體實現(xiàn)，使用相同的技術(shù)，不同的人會有不同的實現(xiàn)方式，這個并不是框架優(yōu)劣的主要決定因素。一個框架的好和壞，在于每層以及層和層之間的設計，這個設計包括：（注：這只是我個人的想法）：
首先，是所采用的解決方案，它是框架的靈魂，是思想，所有的實現(xiàn)都是解決方案的外在體現(xiàn)，就像建筑的架構(gòu)（當然，這也許和平臺所提供的技術(shù)有關(guān)系）；
然后，在解決方案確定后，就是根據(jù)平臺所提供的技術(shù)，確定適合的技術(shù)方案，就像各部分采用何種材料；
最后，才是詳細設計和實現(xiàn)，用采用的技術(shù)實現(xiàn)功能，提供可用于項目開發(fā)的框架。
如果要做新的框架，所作的工作只是將現(xiàn)在的框架進行照搬，進一步完善，再來個優(yōu)化，這樣的框架和原來的框架有什么區(qū)別，那新的框架還有什么用處？原有框架的解決方案可行，但不代表是最優(yōu)的，我們是否可以通過汲取現(xiàn)有.Net平臺的框架或者J2EE的框架的解決方案的精華，選擇當前最優(yōu)的解決方案呢？回答當然是可以的。我們完全可以通過研究做一個針對現(xiàn)有市場上的框架解決方案的詳細說明，說明其適用范圍及優(yōu)缺點。通過比較這些框架的解決方案，在框架的設計中，我們才有可能綜合這些解決方案做出更優(yōu)化的框架。
公司現(xiàn)在進行技術(shù)積累，在我的理解，不單純的只是功能實現(xiàn)的重用，更多的應該是解決方案的積累，這樣，公司的開發(fā)人員才能站在一個更高的高度思考問題。不論是否采用這種方式，但框架解決方案的積累，將會是公司積累的重要組成部分。
有很多方面沒有展開說，只是為了想說明某一點，而只強調(diào)了這一點，而忽略了其他的方面；同時，考慮時間不長，也考慮的不是很周到，觀點不一定正確，可以討論。
