架構(gòu)(Architecture)和框架(Framework)雜談
Posted on 2005-11-22 00:01 非魚(yú) 閱讀(9923) 評(píng)論(11) 編輯 收藏 所屬分類: 面向?qū)ο笤O(shè)計(jì) 經(jīng)常感覺(jué)很多人對(duì)于架構(gòu)和框架分得不是很清楚,隨便寫(xiě)一點(diǎn)關(guān)于這方面的東西吧。如果以后對(duì)于這方面的認(rèn)識(shí)更加深刻的話,再補(bǔ)充好了。
1. 架構(gòu)和框架的設(shè)計(jì)層次不同
類似于硬件設(shè)計(jì),軟件設(shè)計(jì)也分為不同的層次。典型的軟件設(shè)計(jì)層次如下圖:

在這個(gè)圖中我們可以看到,F(xiàn)ramework處于Micro-architectures和Application Level之間。Deisgn Patterns是Micro-architectures級(jí)的設(shè)計(jì),F(xiàn)ramework由多個(gè)Design Pattern和其他微架構(gòu)設(shè)計(jì)元素形成。而Object&classes、Micro-architectures和Framework被稱為 Micro Level設(shè)計(jì)。就是說(shuō),從Objects&classes到Framework,還沒(méi)有發(fā)生質(zhì)變。
對(duì)于Application Level到Global/Industry Level的設(shè)計(jì)來(lái)說(shuō),就都是Architecture的范疇了。從Application Level來(lái)說(shuō),它是由零到多個(gè)Framework組成的獨(dú)立的應(yīng)用程序,會(huì)考慮諸如UI之類的重要問(wèn)題。System Level由多個(gè)應(yīng)用組成,每個(gè)應(yīng)用在整個(gè)系統(tǒng)中代表不同的角色,這些應(yīng)用共同組成一個(gè)系統(tǒng)工作環(huán)境。Enterprise Level又是由System Level組成,通常跨越整個(gè)企業(yè)(這里是廣義的企業(yè))中的多個(gè)組織機(jī)構(gòu)。Global/industry Level由多個(gè)企業(yè)通過(guò)Internet和商業(yè)市場(chǎng)組成一個(gè)相當(dāng)大范圍內(nèi)的系統(tǒng)應(yīng)用,B2B就是這樣的Global Level設(shè)計(jì)的應(yīng)用系統(tǒng)。
顯然Framework和Architecture在這里的差別是巨大的,哪怕和Application Level相比。當(dāng)一個(gè)應(yīng)用中只使用了一個(gè)Framework時(shí),我們可以把它叫做Architecture嗎?事實(shí)上,F(xiàn)ramework僅僅是 Architecture中的一個(gè)微不足道的部分。在Achitecture中,我們考慮技術(shù)視圖時(shí),會(huì)選擇J2EE或.NET,然后才會(huì)考慮:是否要用 Spring、Hibernate?從這里可以看出,F(xiàn)ramework只是技術(shù)視圖的一個(gè)設(shè)計(jì)決策。
2. 架構(gòu)和框架的Design Forces不同
其實(shí),僅僅上面的描述也應(yīng)該能夠讓大家清楚的認(rèn)識(shí)到Architecture和Framework的區(qū)別了。但我還想在另外的方面更進(jìn)一步說(shuō)明。
Design Forces我不知道怎么翻譯,只能解釋一下了:Design Forces指設(shè)計(jì)主要針對(duì)的問(wèn)題、領(lǐng)域和能力。勉強(qiáng)可以翻譯成“設(shè)計(jì)針對(duì)”吧。
Framework的Design Forces主要是功能性、復(fù)雜性和性能。從Framework的定位和設(shè)計(jì)層次來(lái)說(shuō),它主要目的是幫助開(kāi)發(fā)人員完成公共的、系統(tǒng)的功能,這些功能在大多 數(shù)應(yīng)用中都需要,差別在于多少而已。對(duì)于一個(gè)Framework,完成系統(tǒng)的功能,隱藏并盡量簡(jiǎn)化這些系統(tǒng)功能的復(fù)雜性,同時(shí)提供可接受的性能,這就是它 的設(shè)計(jì)目標(biāo)了。
而對(duì)于Architecture,其最主要的Design Force就是變更。其次,所有可能的問(wèn)題都是要在Architecture中考慮:復(fù)雜性、功能、性能、技術(shù)、所有非功能需要等等。。。
3. OOP、AOP還是FOP(Framework oriented Programming)?!
做Java有一個(gè)好處,就是各種框架技術(shù)層出不窮,使用方便。但這不見(jiàn)得就是好事情。感覺(jué)很多人非常專注于框架的使用和研究,對(duì)框架注意力 甚至超過(guò)了對(duì)OO、Java、J2EE規(guī)范等基本的東西的注意力。倒是有些象當(dāng)初Windows下面,用VB、VC、Delphi,還是 CBuilder?似乎有些人把OOP、AOP變成了FOP。
在我看來(lái),框架這個(gè)東西,用用是可以的,研究就不必了;自己寫(xiě)個(gè)框架也是可以的,但也不應(yīng)該停留在框架這個(gè)層次。不要在框架上浪費(fèi)精力,把這個(gè)事情交給畢業(yè)生做好了。
4. 慎用Framework!
小標(biāo)題夸張一點(diǎn),是為了提醒大家。一般情況下,使用Framework可以大大減少工作量,使開(kāi)發(fā)變得容易。通常使用框架應(yīng)該是值得鼓勵(lì)的。但是也要注意:
關(guān)于架構(gòu)和框架,可以用一首詩(shī)來(lái)做結(jié):
橫看成嶺側(cè)成峰,遠(yuǎn)近高低各不同。
不識(shí)廬山真面目,只緣身在此山中。
1. 架構(gòu)和框架的設(shè)計(jì)層次不同
類似于硬件設(shè)計(jì),軟件設(shè)計(jì)也分為不同的層次。典型的軟件設(shè)計(jì)層次如下圖:
在這個(gè)圖中我們可以看到,F(xiàn)ramework處于Micro-architectures和Application Level之間。Deisgn Patterns是Micro-architectures級(jí)的設(shè)計(jì),F(xiàn)ramework由多個(gè)Design Pattern和其他微架構(gòu)設(shè)計(jì)元素形成。而Object&classes、Micro-architectures和Framework被稱為 Micro Level設(shè)計(jì)。就是說(shuō),從Objects&classes到Framework,還沒(méi)有發(fā)生質(zhì)變。
對(duì)于Application Level到Global/Industry Level的設(shè)計(jì)來(lái)說(shuō),就都是Architecture的范疇了。從Application Level來(lái)說(shuō),它是由零到多個(gè)Framework組成的獨(dú)立的應(yīng)用程序,會(huì)考慮諸如UI之類的重要問(wèn)題。System Level由多個(gè)應(yīng)用組成,每個(gè)應(yīng)用在整個(gè)系統(tǒng)中代表不同的角色,這些應(yīng)用共同組成一個(gè)系統(tǒng)工作環(huán)境。Enterprise Level又是由System Level組成,通常跨越整個(gè)企業(yè)(這里是廣義的企業(yè))中的多個(gè)組織機(jī)構(gòu)。Global/industry Level由多個(gè)企業(yè)通過(guò)Internet和商業(yè)市場(chǎng)組成一個(gè)相當(dāng)大范圍內(nèi)的系統(tǒng)應(yīng)用,B2B就是這樣的Global Level設(shè)計(jì)的應(yīng)用系統(tǒng)。
顯然Framework和Architecture在這里的差別是巨大的,哪怕和Application Level相比。當(dāng)一個(gè)應(yīng)用中只使用了一個(gè)Framework時(shí),我們可以把它叫做Architecture嗎?事實(shí)上,F(xiàn)ramework僅僅是 Architecture中的一個(gè)微不足道的部分。在Achitecture中,我們考慮技術(shù)視圖時(shí),會(huì)選擇J2EE或.NET,然后才會(huì)考慮:是否要用 Spring、Hibernate?從這里可以看出,F(xiàn)ramework只是技術(shù)視圖的一個(gè)設(shè)計(jì)決策。
2. 架構(gòu)和框架的Design Forces不同
其實(shí),僅僅上面的描述也應(yīng)該能夠讓大家清楚的認(rèn)識(shí)到Architecture和Framework的區(qū)別了。但我還想在另外的方面更進(jìn)一步說(shuō)明。
Design Forces我不知道怎么翻譯,只能解釋一下了:Design Forces指設(shè)計(jì)主要針對(duì)的問(wèn)題、領(lǐng)域和能力。勉強(qiáng)可以翻譯成“設(shè)計(jì)針對(duì)”吧。
Framework的Design Forces主要是功能性、復(fù)雜性和性能。從Framework的定位和設(shè)計(jì)層次來(lái)說(shuō),它主要目的是幫助開(kāi)發(fā)人員完成公共的、系統(tǒng)的功能,這些功能在大多 數(shù)應(yīng)用中都需要,差別在于多少而已。對(duì)于一個(gè)Framework,完成系統(tǒng)的功能,隱藏并盡量簡(jiǎn)化這些系統(tǒng)功能的復(fù)雜性,同時(shí)提供可接受的性能,這就是它 的設(shè)計(jì)目標(biāo)了。
而對(duì)于Architecture,其最主要的Design Force就是變更。其次,所有可能的問(wèn)題都是要在Architecture中考慮:復(fù)雜性、功能、性能、技術(shù)、所有非功能需要等等。。。
3. OOP、AOP還是FOP(Framework oriented Programming)?!
做Java有一個(gè)好處,就是各種框架技術(shù)層出不窮,使用方便。但這不見(jiàn)得就是好事情。感覺(jué)很多人非常專注于框架的使用和研究,對(duì)框架注意力 甚至超過(guò)了對(duì)OO、Java、J2EE規(guī)范等基本的東西的注意力。倒是有些象當(dāng)初Windows下面,用VB、VC、Delphi,還是 CBuilder?似乎有些人把OOP、AOP變成了FOP。
在我看來(lái),框架這個(gè)東西,用用是可以的,研究就不必了;自己寫(xiě)個(gè)框架也是可以的,但也不應(yīng)該停留在框架這個(gè)層次。不要在框架上浪費(fèi)精力,把這個(gè)事情交給畢業(yè)生做好了。
4. 慎用Framework!
小標(biāo)題夸張一點(diǎn),是為了提醒大家。一般情況下,使用Framework可以大大減少工作量,使開(kāi)發(fā)變得容易。通常使用框架應(yīng)該是值得鼓勵(lì)的。但是也要注意:
- 不要濫用Framework。不要在一個(gè)不是很大的項(xiàng)目中使用過(guò)多的Framework,不然維護(hù)會(huì)受到影響。
- 盡量不要同時(shí)使用幾個(gè)功能上有交叉的Framework。這會(huì)使項(xiàng)目開(kāi)發(fā)的管理更加復(fù)雜,同樣會(huì)導(dǎo)致維護(hù)問(wèn)題。
- 在Enterprise Level的應(yīng)用中使用Framework時(shí),要對(duì)Framework進(jìn)行嚴(yán)格的評(píng)估,確保其Design Forces不和Enterprise Level的應(yīng)用沖突!Framework在設(shè)計(jì)時(shí)刻通常不會(huì)考慮到Enterprise Level的問(wèn)題,你不能想當(dāng)然的認(rèn)為它一定可以適合你的Enterprise應(yīng)用!
關(guān)于架構(gòu)和框架,可以用一首詩(shī)來(lái)做結(jié):
橫看成嶺側(cè)成峰,遠(yuǎn)近高低各不同。
不識(shí)廬山真面目,只緣身在此山中。