框架设计时强制性依赖以及非依赖式约定的考虑

    在框架的设计中，例如struts，我们知道对于每个用户定制action都需要继承strtus的action，此乃典型的方式，这种方式的弊端是对框架依赖严重，不利于系统的移植，另一种方式是针对用户的类，不进行任何框架接口类的继承或者实现，只通过形式上进行约束，例如针对每个execute方法，框架不提供任何超类，只是口头的约定用户需要使用框架则必须自行实现该方法，不提供任何强制性的约束，这种方式的好处是用户定制的action可在代码实现上避免对框架的依赖，然而却因为没有固定约束，导致容易出现错误。

    第一种方式是传统的解决方案，利弊大家也都知道，第二种方式虽然容易让使用的用户犯错，不过可以减轻应用对框架的依赖程度，而且通过框架详细指导可以减少用户犯错的机会，为了减少框架依赖此种做法是否有可取的价值？在此希望各位高手不吝赐教。

框架可以减少用户的编程量，把复杂的事情变简单，加快开发速度，使用框架没什么不好的。

我没有说不使用框架啊，我是说换种更轻便的约束方式来设计框架，尽量避免依赖框架，例如我们不对请求处理的方法进行任何类型上的约束，而是通过一种口头的约定，或者通过annotation指定请求处理的action，而不进行action的继承，这样就可以使用任何用户定制的bean来作为action，而不需要继承框架的action，只是这样对于用户定制的bean就没有任何类型上的约束，不知道我是否说得够清楚。

就现在的趋势看第一种方式逐渐被第二种方式所取代 像 struts2 就是采用
个人认为约定跟继承其用意是一样的 都是为了规范客户端，让客户端遵守一定的规则

那么约定比继承到底好在那儿呢？
在struts1.X中我们要实现的方法是execute（....）参数是钉死的
在struts2中要实现的方法似乎比较简单String doXXX（），对方法的约束非常的宽松

约定比继承更加的宽松 自由度更大
约定没有侵入性

宽松,自由度大,没有侵入性等等并不是POJO带来的益处,很直接的,POJO能带来测试的方便性和降低在不同框架,不同访问方式下代码移植的成本

另外,在我看来,这二种方式如果只是简单的依靠约定,而框架不提供额外的功能,它们并没有本质的区别,也没有压倒性的优点(除了上面优点)
而真正发挥框架能力的应该是客户端+框架本身

宽松,自由度大,没有侵入性自然就利于测试以及移植等，这并不冲突。


上面所说的优点还不够吗？很多框架在宣传时往往都是以这些优点为主，但是最终能够很好的做到这些优点的好象并不多。


这句我还无法很好的理解，客户端是指。。。。。。？

框架的侵入性并不影响可测试性，也不一定影响灵活性。开发效率在企业应用中才是一锤子定音的东西。代码写的少，好维护，那就行了。不要给低侵入性蒙住了眼睛。