框架为我所用，勿为框架所困

我们已经被框架所包围，我们已陷入了学习之苦。

了解算法，设计模式，语言特性，就可以成为一名合格的程序员了吗？理论上是的，但仅仅如此，却不足以找到一份理想的差事，因为众多的招聘信息上都明确注明，应聘者应当熟悉xx框架，yy组件。

由于长期接受中国式教育，所以我们已经习惯了学习，学习几个框架，对于国人来说也不是什么大不了的事情，然而我们也发现，相对于我们的学习能力而言，我们的创造性显得有些不足，我们有了继承他人的能力，我们也缺乏一种颠覆他人的精神。

谦虚的说，我是一名java的初学者，狂妄的说，我并不比所谓高手差多少，他们不过是多了解一些框架，走的路比我过的桥多一些。

作为一名初学者，这大半年以来在倒腾各种框架，时间有些，虽然无法精通任何一项，还是对一些框架有所了解了。spring，hibernate，struts2，log4j, dom4j 都是很棒的。

作为一个不觉得自己比高手差的人，曾经写过篇《被我抛弃的开源框架》，部分人与我有同感，更多的人对我的这种不尊重他们所推崇的框架的态度表示反对，甚至是愤怒。这几个框架是GWT,TAPESTRY5,STRUTS 1.X,GRAILS, ROR。都是表示层的框架。

此时，鄙人想再次不知天高地厚的批评一下目前两种流行的开发习惯。

1. 使用spring的 HibernateDaoSupport 编写 Dao 代码。

  spring 封装了事务管理，使用 HibernateDaoSupport被迫使用spring的事务管理，当Dao不能正常工作后，很难寻找到问题所在，常见的有lazyload的问题，OpenSessionInViewFilter 的 ReadOnly 的问题。

虽然好奇心驱使我想去了解，他人是如何解决这些问题的，想去彻底学习 spring的事务管理。 但理智的想一下，这根本就是庸人自扰，不使用spring dao，Dao 的问题可能出现在Hibernate的使用上，使用了spring dao，问题可能出现在spring dao的使用上和Hibernate的使用上，既然已经确定问题出在spring dao的使用上，为何不直接使用Hibernate编写dao，自己管理session， ThreadLocal 的模式在80％ 的应用中我想都是可以满足要求的。如此一试，发现好处有三：

a, 所有和session生命周期的问题解决了；
b, 代码变得清晰了，以前为了在TestCase中模仿 OpenSessionInViewFilter 还专门写SetUp和TearDown，现在我的session我作主；
c, 性能提升了，对于大批量的CRUD操作，性能至少提高100%。

  spring框架最好用的是它的IOC容器，最大的问题是内容庞杂，太追求面面俱到，细节的学习点多。

  当我们使用他人提供的工具时，最大的弊病是太多的细节被隐藏了，如果像log4j这样的细节无关紧要的工具也就无所谓了，Dao ， Service 这样的核心代码，太多细节被隐藏，是很危险的，也许解决一个细节问题的时间，超过了编写一个核心算法的时间，时间浪费在了不能对产品对质量有所提高的地方。此外，如果他人的工具有着设计上的缺陷，或者bug，那问题就更大了。

当然，我们不能抱着对框架完全不信任的态度来对待框架，我想小学生守则上的话能很好的概括我的观点：自己能做的事情自己做。

2. aop

  首先必须肯定，aop真的是很牛B的创意。但我认为，aop 应该是用于解决特殊问题，而不应该作为架构的基础。所谓特殊问题，比如Hibernate的LazyLoad特性，是通过拦截getters实现的，的确是非aop不可以为之。
 
  aop 在架构中也有很多应用，如，权限管理。

  但眼下 aop 颇有滥用之势，如aop文章中经常提到的用于异常处理的aop模式，鄙人就不敢苟同。

  a, 不使用 aop 同样可以做到异常的一致性处理。对于全局的异常记录方式，无论是使用Log4j还是自己编写的Logger，都可以在Logger这一类中得到一致性的控制。对于代码的冗余，可以使用callback模式，比如HibernateTemplate.excute(HibernateCallback)。

  b, aop 会对性能产生影响。

  c, aop 是基于方法拦截的，是基于java语言特性的，不能够放之四海，因此，不宜过于依赖，它应用来实现一些与众不同的功能，而不是解决问题的首先。

  d, aop 限定了对象创建的方式，只能是从工厂模式中创建的对象，或者Ioc容器中取出的对象。

个人拙见，欢迎拍砖。

有一定道理。
不过对于“自己能做的事情自己做”，这句话本身可解释的余地很大，就不讨论了。

目前有点象乱世吧。

"框架为我所用，勿为框架所困" 写得不错.

大部分都是为了框架而去使用框架，大有甚者是为了流行而用，称滥用。

1 Dao.
如果是jpa,那岂不更"不能控制"?
个人认为dao只是一个中间产物,框架的不够成熟而产生的.
dao本来就不怎么样,再在外面包装,当然就更容易出问题了.

2 aop.
不成熟不敢用,自已实现一般更不可取.
理由同上.
这个基本和楼主同.

总的来说,如果你不了解基本的内部机制,可能刚开始还认为能上手,但马上你就会crack up.
不然,jboss,interface21这些公司怎么赚钱?

当水平越来越高的时候 框架用起来越来越得心应手
相反让一个新手用spring hibernate反而会让他们不知所错 摸不着头脑 出了错也很难找到源头

当你的程序重复代码越来越多 维护越来越难的时候 你自然就会用框架或者自己开发框架了
没有必要把每一个框架都研究透彻。 先大概了解一下各种框架，当项目中需要的时候再去深入

有同感，由与工作原因，我接触到的java初学者很多，流行的这些东东，对初学者产生了很不好的影响！他们经常问些这样的问题：
  "hibernate里怎么连mysql....
  "Struts怎么弹出一个对话框...
  "struts里怎么del一个己上传的文件...

   使得java世界，对许多初学都来说是一片混乱，除了SSH，好似不知有其它可学的；言必称SSH，但知道Class.forName("...")只能用来装载DB Driver。

　我理解这也正常，以前，新婚入洞房时，都要先吼声“毛ＸＸ万岁”，才可行事；现在，凡事先举“八荣八耻”大旗；java程序员群中，不说SSH,你都不好意思开口－－－这种文化传统，是很难逃的开的。

    这并不是说我们习惯了学习，这一点也不象“乱世”,开放的java提供给了程序员更多的选择的自由和乐趣,但对与没有选择能力或都说不习惯选择的人来说，还是习惯盲从。
  

谁给挪一下吧，这帖子怎么会在新手区呢？晕。

写得不错，现在也开始看看源码了，Java基础很重要，Class.forName 这个说得很好，有空学学那些框架，不如把一门框架得源码掌握了，其他得都没什么。其实相似得框架没有必要学，如Struts和webwork。学一种就行了。
一家之言。

不至于被搞成新手帖，给个良好

还是ajoo和一刀识货，感谢。