BlogJava 联系 聚合 管理  

Blog Stats

News

近期活动:

随笔分类

随笔档案

朋友的BLOG

社区


无言独上西楼,月如钩,寂寞梧桐深夜锁清秋

  早就想写点有关框架的文字了,一直懒得去写。前段时间看了一个朋友(就是那条不是鱼的鱼)写的BLOG架构(Architecture)和框架(Framework)杂谈,想起了一两年前在TSS上看到的一幅卡通,于是便先到TSSsearch了一下,卡通的标题是:Framework Lock-In

  这幅卡通明白地表明了这么一个观点:框架束缚了开发人员。隐藏其后的意思是:框架束缚了项目。但这是真的吗?

  我有一个大学同学,在他做一个省级项目的项目经理时,我和他在电话里聊过一些他那个项目的话题。因为据我所知他所管理的那个项目进展一直比较顺利。我记得有一个是关于EJB(当然主要是SessionBean)的使用问题。他说他们在项目中没有使用EJB。我很诧异,因为在我看来,使用SessionBeanFlat事务的管理,还是蛮方便的。他告诉我的原因其实也非常简单:我也想用EJB来做事务控制,但我手下那帮兄弟能写写JSPServlet就很不错了,如果用EJB,还不知要出什么问题。对于他的回答,我的理解是:用自己团队最熟悉的技术,而不是最时髦的技术

   好了,回到这个框架问题上来吧。任何一种技术都可以解决一些问题,但与此同时,它也会带来一些问题。框架自然不会例外。这并不说我们不要去使用框架,而 是我们要合理的使用框架。在确定使用一个框架之前,要明确这个框架能解决我们什么样的问题?能解决多少?会带来哪些问题?带来的问题我们有没有办法避免, 还是可以忽略?它会影响我们现有的哪些组件和框架?团队对这个框架的熟悉程度和学习能力如何?它的成熟度如何?如果是商业化的框架,那么要考察提供该框架 的公司的情况,以确保支持和服务;如果是开源的框架,则应看看它的使用情况,项目的活跃程度等,如有可能最好是能view一下源代码,因为目前开源项目水平良莠不齐,设计和编码良好的项目并不多。等等诸如此类的问题。

  正如非鱼所说,有一些原则性的规则,比如说不要在一个项目中使用作用域交叉过多的框架;不要用框架来堆砌项目等等。

  让我们再看看这幅卡通。我个人认为这幅卡通隐藏着一个更深层的喻义。是谁给程序员们套上枷锁的?是谁把框架硬套在程序员们的脚上的?对了,就是那个西装革履,还打着领带的家伙。这家伙是谁?呵呵,大家自己去想吧。

posted on 2005-12-09 17:38 无言独上西楼 阅读(705) 评论(0)  编辑  收藏 所属分类: 巴山夜语

只有注册用户登录后才能发表评论。


网站导航: