早就想寫(xiě)點(diǎn)有關(guān)框架的文字了，一直懶得去寫(xiě)。前段時(shí)間看了一個(gè)朋友（就是那條不是魚(yú)的魚(yú)）寫(xiě)的BLOG：架構(gòu)（Architecture）和框架（Framework）雜談，想起了一兩年前在TSS上看到的一幅卡通，于是便先到TSS上search了一下，卡通的標(biāo)題是：Framework
Lock-In
這幅卡通明白地表明了這么一個(gè)觀點(diǎn)：框架束縛了開(kāi)發(fā)人員。隱藏其后的意思是：框架束縛了項(xiàng)目。但這是真的嗎？
我有一個(gè)大學(xué)同學(xué)，在他做一個(gè)省級(jí)項(xiàng)目的項(xiàng)目經(jīng)理時(shí)，我和他在電話里聊過(guò)一些他那個(gè)項(xiàng)目的話題。因?yàn)閾?jù)我所知他所管理的那個(gè)項(xiàng)目進(jìn)展一直比較順利。我記得有一個(gè)是關(guān)于EJB（當(dāng)然主要是SessionBean）的使用問(wèn)題。他說(shuō)他們?cè)陧?xiàng)目中沒(méi)有使用EJB。我很詫異，因?yàn)樵谖铱磥?lái)，使用SessionBean做Flat事務(wù)的管理，還是蠻方便的。他告訴我的原因其實(shí)也非常簡(jiǎn)單：我也想用EJB來(lái)做事務(wù)控制，但我手下那幫兄弟能寫(xiě)寫(xiě)JSP和Servlet就很不錯(cuò)了，如果用EJB，還不知要出什么問(wèn)題。對(duì)于他的回答，我的理解是：用自己團(tuán)隊(duì)最熟悉的技術(shù)，而不是最時(shí)髦的技術(shù)。
好了，回到這個(gè)框架問(wèn)題上來(lái)吧。任何一種技術(shù)都可以解決一些問(wèn)題，但與此同時(shí)，它也會(huì)帶來(lái)一些問(wèn)題?？蚣茏匀徊粫?huì)例外。這并不說(shuō)我們不要去使用框架，而
是我們要合理的使用框架。在確定使用一個(gè)框架之前，要明確這個(gè)框架能解決我們什么樣的問(wèn)題？能解決多少？會(huì)帶來(lái)哪些問(wèn)題？帶來(lái)的問(wèn)題我們有沒(méi)有辦法避免，
還是可以忽略？它會(huì)影響我們現(xiàn)有的哪些組件和框架？團(tuán)隊(duì)對(duì)這個(gè)框架的熟悉程度和學(xué)習(xí)能力如何？它的成熟度如何？如果是商業(yè)化的框架，那么要考察提供該框架
的公司的情況，以確保支持和服務(wù)；如果是開(kāi)源的框架，則應(yīng)看看它的使用情況，項(xiàng)目的活躍程度等，如有可能最好是能view一下源代碼，因?yàn)槟壳伴_(kāi)源項(xiàng)目水平良莠不齊，設(shè)計(jì)和編碼良好的項(xiàng)目并不多。等等諸如此類(lèi)的問(wèn)題。
正如非魚(yú)所說(shuō)，有一些原則性的規(guī)則，比如說(shuō)不要在一個(gè)項(xiàng)目中使用作用域交叉過(guò)多的框架；不要用框架來(lái)堆砌項(xiàng)目等等。
讓我們?cè)倏纯催@幅卡通。我個(gè)人認(rèn)為這幅卡通隱藏著一個(gè)更深層的喻義。是誰(shuí)給程序員們套上枷鎖的？是誰(shuí)把框架硬套在程序員們的腳上的？對(duì)了，就是那個(gè)西裝革履，還打著領(lǐng)帶的家伙。這家伙是誰(shuí)？呵呵，大家自己去想吧。