常用體系結(jié)構(gòu)

層次體系

　　層次體系就是利用分層的方式來處理復(fù)雜的功能，層次系統(tǒng)要求上層子系統(tǒng)可以使用下層子系統(tǒng)的功能，而下層子系統(tǒng)不能夠使用上層子系統(tǒng)的功能。一般下層每個(gè)程序接口執(zhí)行當(dāng)前的一個(gè)簡單的功能，而上層通過調(diào)用不同的下層程序，并按不同的順序來執(zhí)行這些下層程序，層次體系就是以這種方式來完成多個(gè)復(fù)雜的業(yè)務(wù)功能的。

客戶機(jī)/服務(wù)器結(jié)構(gòu)

　　客戶機(jī)/服務(wù)器結(jié)構(gòu)簡稱C/S結(jié)構(gòu)或稱兩層結(jié)構(gòu)。　　　　　　　　　　　

　　客戶/服務(wù)器應(yīng)用模式的特點(diǎn)是大都基于“肥客戶機(jī)”結(jié)構(gòu)下的兩層結(jié)構(gòu)應(yīng)用軟件。客戶端軟件一般由應(yīng)用程序及相應(yīng)的數(shù)據(jù)庫連接程序組成。服務(wù)器端軟件一般是某種數(shù)據(jù)庫系統(tǒng)。

　　　
   三層次客戶機(jī)/服務(wù)器結(jié)構(gòu)和瀏覽器/服務(wù)器結(jié)構(gòu)的數(shù)據(jù)庫服務(wù)器管理端由于客戶端連接數(shù)少，也常采用C/S結(jié)構(gòu)。  

瀏覽器/服務(wù)器結(jié)構(gòu)

　　“瀏覽器/服務(wù)器”結(jié)構(gòu)是當(dāng)前非常流行的客戶機(jī)/服務(wù)器結(jié)構(gòu)，簡稱B/S結(jié)構(gòu)。
　　　　　　　

　　這種結(jié)構(gòu)最大的優(yōu)點(diǎn)是：客戶機(jī)統(tǒng)一采用瀏覽器，這不僅讓用戶使用方便，而且使得客戶機(jī)不存在及安裝維護(hù)的問題。 

三層次客戶機(jī)/服務(wù)器結(jié)構(gòu)

　　三層次客戶機(jī)/服務(wù)器結(jié)構(gòu)是在常規(guī)客戶機(jī)/服務(wù)器結(jié)構(gòu)上提出的，系統(tǒng)在客戶機(jī)和數(shù)據(jù)庫服務(wù)器間添加一個(gè)應(yīng)用服務(wù)器。

框架擴(kuò)展

（1）所支持系統(tǒng)體系結(jié)構(gòu)的擴(kuò)展

以上介紹的體系結(jié)構(gòu)，都是較為流行的，應(yīng)用的范圍比較廣，我們的框架必須要支持不同的系統(tǒng)結(jié)構(gòu)，以滿足不同系統(tǒng)的要求，這里既包括業(yè)務(wù)的要求，也包括項(xiàng)目成本的要求以及其他。

當(dāng)前公司所使用的框架可以支持三層客戶機(jī)/服務(wù)器結(jié)構(gòu)項(xiàng)目的開發(fā)，如果用來開發(fā)同是Windows應(yīng)用并且要求快速的客戶機(jī)/服務(wù)器結(jié)構(gòu)的項(xiàng)目，框架將會(huì)變得臃腫不堪，那么框架的優(yōu)勢不能完全體現(xiàn)，而且還會(huì)造成部署和維護(hù)的困難。

開發(fā)框架的目的是提高項(xiàng)目的開發(fā)效率，所以為了適應(yīng)不同體系結(jié)構(gòu)和進(jìn)度要求的項(xiàng)目，需要有相對(duì)應(yīng)的框架支持開發(fā)。比如要求快速并且可以選取客戶端/服務(wù)器體系結(jié)構(gòu)相對(duì)小型的項(xiàng)目，成本低，而且系統(tǒng)使用范圍也只是局域網(wǎng)，那么此系統(tǒng)的體系結(jié)構(gòu)可以采用支持客戶機(jī)/服務(wù)器的框架；如果項(xiàng)目屬于分布式的應(yīng)用，使用三層次客戶機(jī)/服務(wù)器體系結(jié)構(gòu)，那么可以使用支持三層次客戶機(jī)/服務(wù)器結(jié)構(gòu)的框架等。

根據(jù)現(xiàn)有常用的體系結(jié)構(gòu)，至少有對(duì)應(yīng)的三套框架：針對(duì)客戶機(jī)/服務(wù)器結(jié)構(gòu)的框架、三層次客戶機(jī)/服務(wù)器結(jié)構(gòu)的框架以及瀏覽器/服務(wù)器結(jié)構(gòu)的框架。（并不是說要有三套獨(dú)立的框架代碼，三套框架共有的組件可以復(fù)用，比如數(shù)據(jù)訪問層，比如通用接口等）

（2）技術(shù)的擴(kuò)展

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

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

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

建議

（1）       我們所做的工作不能以.NET或者Java平臺(tái)來區(qū)分，不能說使用.NET，就拒絕Java。簡單一點(diǎn)，它們都只是工具，我們應(yīng)該更多的去關(guān)注在它們之上并且是想通的思想。

舉個(gè)例子，企業(yè)級(jí)應(yīng)用的開發(fā)首選是J2EE，針對(duì)J2EE的表示層、邏輯層和數(shù)據(jù)持久層都有很多免費(fèi)并且應(yīng)用成熟的框架，而現(xiàn)在基于.NET的還沒有這樣具有影響力、成熟的框架。我們不是說要用J2EE的框架，至少我們應(yīng)該有意識(shí)的去了解它們，了解它們的工作原理，了解它們的設(shè)計(jì)思想，了解它們的應(yīng)用范圍，了解它們的優(yōu)缺點(diǎn)等，然后將這些總結(jié)運(yùn)用到.NET平臺(tái)。有巨人的肩膀給你支撐，難道就因?yàn)樗皇屈S皮膚，我們就強(qiáng)烈地拒絕？

（2） 不論是在.NET平臺(tái)還是Java平臺(tái)，我們所要做的不僅僅只是局限于將現(xiàn)在的框架在不同的平臺(tái)上實(shí)現(xiàn)（相當(dāng)于將框架從.NET平臺(tái)轉(zhuǎn)換為Java平臺(tái)），這樣的工作沒有太大的意義，因?yàn)槲覀兯龅闹皇窃诠δ軐?shí)現(xiàn)上進(jìn)行修修補(bǔ)補(bǔ)，框架始終停留在初始水平，進(jìn)步可能只局限于技術(shù)的實(shí)現(xiàn)或者算法的優(yōu)化，這樣的做法將會(huì)限制框架的發(fā)展。極端一點(diǎn)，就像一個(gè)人的思想認(rèn)識(shí)停留在遠(yuǎn)古，顯然無法滿足社會(huì)進(jìn)步的要求。

對(duì)框架的具體實(shí)現(xiàn)，使用相同的技術(shù)，不同的人會(huì)有不同的實(shí)現(xiàn)方式，這個(gè)并不是框架優(yōu)劣的主要決定因素。一個(gè)框架的好和壞，在于每層以及層和層之間的設(shè)計(jì)，這個(gè)設(shè)計(jì)包括：（注：這只是我個(gè)人的想法）：

首先，是所采用的解決方案，它是框架的靈魂，是思想，所有的實(shí)現(xiàn)都是解決方案的外在體現(xiàn)，就像建筑的架構(gòu)（當(dāng)然，這也許和平臺(tái)所提供的技術(shù)有關(guān)系）；

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

最后，才是詳細(xì)設(shè)計(jì)和實(shí)現(xiàn)，用采用的技術(shù)實(shí)現(xiàn)功能，提供可用于項(xiàng)目開發(fā)的框架。

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

 公司現(xiàn)在進(jìn)行技術(shù)積累，在我的理解，不單純的只是功能實(shí)現(xiàn)的重用，更多的應(yīng)該是解決方案的積累，這樣，公司的開發(fā)人員才能站在一個(gè)更高的高度思考問題。不論是否采用這種方式，但框架解決方案的積累，將會(huì)是公司積累的重要組成部分。

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

it知識(shí)庫：框架的建議，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。