框架的侵入性问题是不是一个伪问题？

本来想说点什么，都懒得说了。

呵呵，既然来了，总得说两句吧

对反射充满了畏惧啊，呵呵，struts不就是利用反射实现的吗，我还没有见过不用反射的mvc框架呢，可能自己学艺不精吧，struts的毛病可不止单元测试这么简单，还有并不是继承了什么，实现了什么，struts的性能就高了，如果你去看看webwork2，jsf，tapestry的用法和实现（不需要精通他们，就看看人家是怎么用的）在回来跟贴估计就不会这么说了。你对反射很畏惧，那一定不喜欢用spring吧，因为那里面的反射也多的是

晕死……看来是我表述有问题了。

据说struts最大的毛病是不利于单元测试。 这句是针对这个：




说实话，有时候我宁可它没有那么优雅，宁可去继承去实现什么，以换来高性能。 这句是针对这里说的：


本人对反射充满了畏惧，呵呵。  这一句是针对setter注入的。可能用词夸张了点，呵呵。这个就好像某些人反对用"+"连接大量字符串一样，各人遇到的环境不一样，不能一概而论。

呵呵，跳跃太大了，让人误会我的意思，好像我是struts的忠实fans一样。

         我的理解是所谓的‘非侵入’性应该是指代码中对框架的代码的调用多少和依赖程度，像struts和hibernate这样的框架是肯定需要你依赖于它的。因为你的action不得不继承基类action，你不得不调用hibernate的session对象。而像spring这样的框架本身就是为了减少这样的依赖性而实现的‘框架’，它达到这个目的采用的方式正好就是ioc。这也正是spring这个框架区别于其他框架的地方。

        要想做到绝对不依赖于任何的框架是不可能的，除非你什么都去自己’制造‘。而spring框架集成了其他很多的框架，比如hibenrate，struts什么的。它这样做的目的也无非是：要么你不依赖于他们，如果你实在要依赖于他们的话，就让我来依赖他们吧，而你们只需要依赖于我。正所谓’我不入地狱，谁入地狱‘，对于其他框架的繁琐的操作接口和一些版本的冲突spring都试着自己来解决或作出一些‘封装’，来简化我们对其操作的复杂性。

        个人觉得spring的这种设计方式还是非常先进的，只是其自身正在因为这种方式而变得越来越臃肿和庞大。变得不堪重负，因为我们在开发中经常因为不了解其对于其他的框架的集成方式而不知如何解决一些具体的问题。虽然我不依赖于他们了，但是因为中间多了一个你（spring）而让本来简单的事情变得更加的扑朔迷离！！

       个人认为这正是spring在发展过程中需要注意平衡’强大性‘和’简单性‘这二者的挑战极大的地方。因为一不小心它可能就发展成为了一个新的’开发平台‘，而所谓的’非侵入行‘和’简单性‘就又变成了一句空话！！！

       个人意见，希望大家指正！