Nice Struts～鸡肋问题解决之道

还有就是历史遗留问题，刚才有网友说了利用注解解决零配置的问题，在我们公司暂时不可能采用的。

因为客户那里有不少环境就是不支持JDK1.5的，我们也没有办法。

还有就是IDE的问题，如果IDE对XML的生成和重构能够达到Java的程度，也不会有那么多人抱怨重载的XML配置文件了。

如果IDE没有良好支持get和set代码的生成，一样会有很多人骂娘直到质疑标准JavaBean规范的低开发效率。

华山论剑总是要有规则的，除非楼主你事先定好前提，例如：只讨论开发效率，不考虑其他相关成本。这样就可以了。

楼上所谈的确实是我们选择技术架构时必须考虑的问题，相信对大家都有启发性的意义，感觉咱们的讨论太发散了，呵呵。如有必要建议另立贴与大家展开讨论这方面的话题，否则java阿姨的管理员要说这个贴没有主题、不知所云、太发散、可能要被评隐藏贴了，呵呵，觉得java阿姨太严厉了点！！

spring mvc很劲爆，加上注解，差不多0配置了

呵呵，o配置，也仅仅是另一场忽悠的风波罢了吧，注解+配置+根据场景选择....唉

零配置个人感觉没啥意义或者说是倒退
配置文件的出现本身上为了保持代码不变的情况下将设置集中管理，注解式配置实际上上走回分散设置的老路，简直类似于JSP中不写<% %>之后有人觉得用起来不够爽又重新拿出<% %>

以ssh的架构，dao+(biz+service)+action+view这样的结构，struts的action层完全可以虚化掉，页面转向控制交给配置文件，业务逻辑集中到service层，用一个base action类来充当中央控制引擎，根据IOC的配置调用与组装service内的业务逻辑，对数据的校验，等等，用自定的map取代request，一方面简化掉了action，另一方面也可以通过替换base action来达到不同的效果，比如输出的数据格式，可以无缝的把struts的form变成json数据，或者xml数据，或者其他什么

听起来是不是有些部分像webwork

Struts2就是webwork2。

不谋而合，这种思路适合很大一部分需求，屏蔽了诸多技术细节，拯救将劳苦大众与技术纠缠的水深火热，对于大规模快速应用层开发大有裨益。楼上一席话总结了一开始例子中对struts的封装思路，赞一个！！！

至于零配置我倒是觉得并非全无意义，零配置针对的是目下java领域配置泛滥的弊端，还是那句话：要配置还是要0配置需要根据具体的应用场景，要因地制宜”识别配置的必要性“，相互结合取长补短，灵活机动的选择。

还是喜欢 Spring 的 MVC 。。

真要零配置，那就从命名上给规范了，使用反射来动态加载（根据一定的名称规则和包结构）。
使用注解那哪叫零配置？？