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