早就想写点有关框架的文字了，一直懒得去写。前段时间看了一个朋友（就是那条不是鱼的鱼）写的BLOG：架构（Architecture）和框架（Framework）杂谈，想起了一两年前在TSS上看到的一幅卡通，于是便先到TSS上search了一下，卡通的标题是：Framework
Lock-In
这幅卡通明白地表明了这么一个观点：框架束缚了开发人员。隐藏其后的意思是：框架束缚了项目。但这是真的吗？
我有一个大学同学，在他做一个省级项目的项目经理时，我和他在电话里聊过一些他那个项目的话题。因为据我所知他所管理的那个项目进展一直比较顺利。我记得有一个是关于EJB（当然主要是SessionBean）的使用问题。他说他们在项目中没有使用EJB。我很诧异，因为在我看来，使用SessionBean做Flat事务的管理，还是蛮方便的。他告诉我的原因其实也非常简单：我也想用EJB来做事务控制，但我手下那帮兄弟能写写JSP和Servlet就很不错了，如果用EJB，还不知要出什么问题。对于他的回答，我的理解是：用自己团队最熟悉的技术，而不是最时髦的技术。
好了，回到这个框架问题上来吧。任何一种技术都可以解决一些问题，但与此同时，它也会带来一些问题。框架自然不会例外。这并不说我们不要去使用框架，而
是我们要合理的使用框架。在确定使用一个框架之前，要明确这个框架能解决我们什么样的问题？能解决多少？会带来哪些问题？带来的问题我们有没有办法避免，
还是可以忽略？它会影响我们现有的哪些组件和框架？团队对这个框架的熟悉程度和学习能力如何？它的成熟度如何？如果是商业化的框架，那么要考察提供该框架
的公司的情况，以确保支持和服务；如果是开源的框架，则应看看它的使用情况，项目的活跃程度等，如有可能最好是能view一下源代码，因为目前开源项目水平良莠不齐，设计和编码良好的项目并不多。等等诸如此类的问题。
正如非鱼所说，有一些原则性的规则，比如说不要在一个项目中使用作用域交叉过多的框架；不要用框架来堆砌项目等等。
让我们再看看这幅卡通。我个人认为这幅卡通隐藏着一个更深层的喻义。是谁给程序员们套上枷锁的？是谁把框架硬套在程序员们的脚上的？对了，就是那个西装革履，还打着领带的家伙。这家伙是谁？呵呵，大家自己去想吧。