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