常用體系結構

層次體系

　　層次體系就是利用分層的方式來處理復雜的功能，層次系統要求上層子系統可以使用下層子系統的功能，而下層子系統不能夠使用上層子系統的功能。一般下層每個程序接口執行當前的一個簡單的功能，而上層通過調用不同的下層程序，并按不同的順序來執行這些下層程序，層次體系就是以這種方式來完成多個復雜的業務功能的。

客戶機/服務器結構

　　客戶機/服務器結構簡稱C/S結構或稱兩層結構。　　　　　　　　　　　

　　客戶/服務器應用模式的特點是大都基于“肥客戶機”結構下的兩層結構應用軟件?？蛻舳塑浖话阌?a href=/pingce/yingyong/ target=_blank class=infotextkey>應用程序及相應的數據庫連接程序組成。服務器端軟件一般是某種數據庫系統。

　　　
   三層次客戶機/服務器結構和瀏覽器/服務器結構的數據庫服務器管理端由于客戶端連接數少，也常采用C/S結構。  

瀏覽器/服務器結構

　　“瀏覽器/服務器”結構是當前非常流行的客戶機/服務器結構，簡稱B/S結構。
　　　　　　　

　　這種結構最大的優點是：客戶機統一采用瀏覽器，這不僅讓用戶使用方便，而且使得客戶機不存在及安裝維護的問題。 

三層次客戶機/服務器結構

　　三層次客戶機/服務器結構是在常規客戶機/服務器結構上提出的，系統在客戶機和數據庫服務器間添加一個應用服務器。

框架擴展

（1）所支持系統體系結構的擴展

以上介紹的體系結構，都是較為流行的，應用的范圍比較廣，我們的框架必須要支持不同的系統結構，以滿足不同系統的要求，這里既包括業務的要求，也包括項目成本的要求以及其他。

當前公司所使用的框架可以支持三層客戶機/服務器結構項目的開發，如果用來開發同是Windows應用并且要求快速的客戶機/服務器結構的項目，框架將會變得臃腫不堪，那么框架的優勢不能完全體現，而且還會造成部署和維護的困難。

開發框架的目的是提高項目的開發效率，所以為了適應不同體系結構和進度要求的項目，需要有相對應的框架支持開發。比如要求快速并且可以選取客戶端/服務器體系結構相對小型的項目，成本低，而且系統使用范圍也只是局域網，那么此系統的體系結構可以采用支持客戶機/服務器的框架；如果項目屬于分布式的應用，使用三層次客戶機/服務器體系結構，那么可以使用支持三層次客戶機/服務器結構的框架等。

根據現有常用的體系結構，至少有對應的三套框架：針對客戶機/服務器結構的框架、三層次客戶機/服務器結構的框架以及瀏覽器/服務器結構的框架。（并不是說要有三套獨立的框架代碼，三套框架共有的組件可以復用，比如數據訪問層，比如通用接口等）

（2）技術的擴展

簡單一點，就拿層層之間通信來說吧?，F在的框架是使用Remoting技術實現客戶端與服務端之間的通信，我們肯定Remoting技術的優點的同時，也要看清Remoting技術的缺點。 鑒于WebService的跨平臺的優點，實現與不同平臺系統之間的交互，完全可以將框架之間的通信技術通過WebService實現，使框架不僅可以滿足了局域網的快速通信的要求（Remoting）,也可以滿足跨平臺的通信的要求(WebService)。

現在.NET 3.0提供的四個功能組件中，其中一個新的功能組是Windows Communication Foundation（WCF），有了WCF，開發人員不必再像從前一樣，處理每一類通信都要使用到不同的應用程序編程接口技術，使得通信應用變得簡單。因此，我們的框架也應該實現基于Windows Communication Foundation技術的通信，而不單純的使用Remoting。

    技術的擴展，不僅包括上面所說的，以前我們沒有使用過的技術，或者是微軟最新提供了新技術，我們都可以考慮是否用于我們的框架，只要這樣的技術有優勢，并符合我們業務的要求。

建議

（1）       我們所做的工作不能以.NET或者Java平臺來區分，不能說使用.NET，就拒絕Java。簡單一點，它們都只是工具，我們應該更多的去關注在它們之上并且是想通的思想。

舉個例子，企業級應用的開發首選是J2EE，針對J2EE的表示層、邏輯層和數據持久層都有很多免費并且應用成熟的框架，而現在基于.NET的還沒有這樣具有影響力、成熟的框架。我們不是說要用J2EE的框架，至少我們應該有意識的去了解它們，了解它們的工作原理，了解它們的設計思想，了解它們的應用范圍，了解它們的優缺點等，然后將這些總結運用到.NET平臺。有巨人的肩膀給你支撐，難道就因為它不是黃皮膚，我們就強烈地拒絕？

（2） 不論是在.NET平臺還是Java平臺，我們所要做的不僅僅只是局限于將現在的框架在不同的平臺上實現（相當于將框架從.NET平臺轉換為Java平臺），這樣的工作沒有太大的意義，因為我們所做的只是在功能實現上進行修修補補，框架始終停留在初始水平，進步可能只局限于技術的實現或者算法的優化，這樣的做法將會限制框架的發展。極端一點，就像一個人的思想認識停留在遠古，顯然無法滿足社會進步的要求。

對框架的具體實現，使用相同的技術，不同的人會有不同的實現方式，這個并不是框架優劣的主要決定因素。一個框架的好和壞，在于每層以及層和層之間的設計，這個設計包括：（注：這只是我個人的想法）：

首先，是所采用的解決方案，它是框架的靈魂，是思想，所有的實現都是解決方案的外在體現，就像建筑的架構（當然，這也許和平臺所提供的技術有關系）；

然后，在解決方案確定后，就是根據平臺所提供的技術，確定適合的技術方案，就像各部分采用何種材料；

最后，才是詳細設計和實現，用采用的技術實現功能，提供可用于項目開發的框架。

如果要做新的框架，所作的工作只是將現在的框架進行照搬，進一步完善，再來個優化，這樣的框架和原來的框架有什么區別，那新的框架還有什么用處？原有框架的解決方案可行，但不代表是最優的，我們是否可以通過汲取現有.NET平臺的框架或者J2EE的框架的解決方案的精華，選擇當前最優的解決方案呢？回答當然是可以的。我們完全可以通過研究做一個針對現有市場上的框架解決方案的詳細說明，說明其適用范圍及優缺點。通過比較這些框架的解決方案，在框架的設計中，我們才有可能綜合這些解決方案做出更優化的框架。

 公司現在進行技術積累，在我的理解，不單純的只是功能實現的重用，更多的應該是解決方案的積累，這樣，公司的開發人員才能站在一個更高的高度思考問題。不論是否采用這種方式，但框架解決方案的積累，將會是公司積累的重要組成部分。

有很多方面沒有展開說，只是為了想說明某一點，而只強調了這一點，而忽略了其他的方面；同時，考慮時間不長，也考慮的不是很周到，觀點不一定正確，可以討論。       

it知識庫：框架的建議，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。