其实struts和spring都比较类似的概念, 分发Controller/Action, Form的概念, View/Forward， 一些专有的form标签等. 所以改用spring的代价应该小一些(相比学习JSF等)会struts的人多就用structs了， 但是又想享受Spring IOC的便利， 只好整合了. 直接使用Spring MVC其实项目会显得简洁点， 和Spring紧密结合. 各种功能你想要的基本都有的了。 好好看下spring reference吧， 但是灵活每个人使用的时候项目没统一好可能会显得松散， 协调好来就好。不知道6楼说的是同一个页面使用多种view技术还是说， 不同页面有不同的view渲染。 Spring的view我觉得还是蛮方便的啊 13.5.2. Chaining ViewResolvers Spring supports more than just one view resolver. This allows you to chain resolvers and, for example, override specific views in certain circumstances. Chaining view resolvers is pretty straightforward - just add more than one resolver to your application context and, if necessary, set the order property to specify an order. Remember,thehighertheorderproperty,thelatertheviewresolverwillbepositionedinthechain. In the following example, the chain of view resolvers consists of two resolvers, a InternalResourceViewResolver (which is always automatically positioned as the last resolver in the chain) and an XmlViewResolver for specifying Excel views (which are not supported by the InternalResourceViewResolver): <bean id="jspViewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver"> <property name="viewClass" value="org.springframework.web.servlet.view.JstlView"/> <property name="prefix" value="/WEB-INF/jsp/"/> <property name="suffix" value=".jsp"/> </bean> <bean id="excelViewResolver" class="org.springframework.web.servlet.view.XmlViewResolver"> <property name="order" value="1"/> <property name="location" value="/WEB-INF/views.xml"/> </bean> <!-- in views.xml --> <beans> <bean name="report" class="org.springframework.example.ReportExcelView"/> </beans> If a specific view resolver does not result in a view, Spring will inspect the context to see if other view resolvers are configured. If there are additional view resolvers, it will continue to inspect them. If not, it will throwanException. You have to keep something else in mind - the contract of a view resolver mentions that a view resolver can return null to indicate the view could not be found. Not all view resolvers do this however! This is because in some cases, the resolver simply cannot detect whether or not the view exists. For example, the InternalResourceViewResolver uses the RequestDispatcher internally, and dispatching is the only way to figure out if a JSP exists - this can only be done once. The same holds for the VelocityViewResolver and some others. Check the Javadoc for the view resolver to see if you're dealing with a view resolver that does not report non-existing views. As a result of this, putting an InternalResourceViewResolver in the chain in a place other than the last, will result in the chain not being fully inspected, since the InternalResourceViewResolver will alwaysreturnaview!
而且和spring结合得很好。
优点很多，我说2个缺点1、提供的父类过多，过散。虽然方便使用。但设计有些过度。而且不利于项目管理的代码统一。
2、因为区分了post/get两种提交方式，所以遇到需要get提交的数据稍多的表单，绑定bean稍显麻烦。可能需要手动干预。不过瑕不掩瑜。
还是一个很好的mvc架构。不过我个人是不打算再用了。呵呵good luck
比如tiles就是tiles的，jsp只能都是jsp的，不能混用，比较麻烦。虽然网上有人通过修改源代码。可以实现多个展现层方案并存。但是还需要改代码，也是够麻烦。没有struts2那样，设置一个type就可以了。爽啊！
我用的版本是2.5.x的，不知道新版本有没有什么变化。
知道的达人来指教一下吧！谢谢good luck
所以改用spring的代价应该小一些(相比学习JSF等)会struts的人多就用structs了， 但是又想享受Spring IOC的便利， 只好整合了. 直接使用Spring MVC其实项目会显得简洁点， 和Spring紧密结合. 各种功能你想要的基本都有的了。 好好看下spring reference吧，
但是灵活每个人使用的时候项目没统一好可能会显得松散， 协调好来就好。不知道6楼说的是同一个页面使用多种view技术还是说， 不同页面有不同的view渲染。 Spring的view我觉得还是蛮方便的啊
13.5.2. Chaining ViewResolvers
Spring supports more than just one view resolver. This allows you to chain resolvers and, for example, override
specific views in certain circumstances. Chaining view resolvers is pretty straightforward - just add more than
one resolver to your application context and, if necessary, set the order property to specify an order.
Remember,thehighertheorderproperty,thelatertheviewresolverwillbepositionedinthechain.
In the following example, the chain of view resolvers consists of two resolvers, a
InternalResourceViewResolver (which is always automatically positioned as the last resolver in the chain)
and an XmlViewResolver for specifying Excel views (which are not supported by the
InternalResourceViewResolver):
<bean id="jspViewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
<property name="viewClass" value="org.springframework.web.servlet.view.JstlView"/>
<property name="prefix" value="/WEB-INF/jsp/"/>
<property name="suffix" value=".jsp"/>
</bean>
<bean id="excelViewResolver" class="org.springframework.web.servlet.view.XmlViewResolver">
<property name="order" value="1"/>
<property name="location" value="/WEB-INF/views.xml"/>
</bean>
<!-- in views.xml -->
<beans>
<bean name="report" class="org.springframework.example.ReportExcelView"/>
</beans>
If a specific view resolver does not result in a view, Spring will inspect the context to see if other view
resolvers are configured. If there are additional view resolvers, it will continue to inspect them. If not, it will
throwanException.
You have to keep something else in mind - the contract of a view resolver mentions that a view resolver can
return null to indicate the view could not be found. Not all view resolvers do this however! This is because in
some cases, the resolver simply cannot detect whether or not the view exists. For example, the
InternalResourceViewResolver uses the RequestDispatcher internally, and dispatching is the only way to
figure out if a JSP exists - this can only be done once. The same holds for the VelocityViewResolver and some
others. Check the Javadoc for the view resolver to see if you're dealing with a view resolver that does not report
non-existing views. As a result of this, putting an InternalResourceViewResolver in the chain in a place other
than the last, will result in the chain not being fully inspected, since the InternalResourceViewResolver will
alwaysreturnaview!
也没准是我配置有问题。献丑献丑哈哈哈哈good luck
如果可以建立清晰的层结构，无论是代码的标准化、开发效率都有很多好处。但是在选择模板的时候，需要注意最好使用官方推荐的模板引擎。
strtus2还没开始用~~等体验过了再说~~O(∩_∩)O~