Spring 3.0 MVC 开发指南[强烈推荐1个小时掌握精华]

各有利弊把，struts2用ognl这种情况会主动生成一个Owner
所以struts2的best practice是二次绑定结合preparable，这样update时候先加载后绑定。
我记得springmvc也有这种能力，但是由于controller的模型原因，可能存在并发问题，所以这种情况恐怕只能自己拷贝一次了。

一阵子不见这楼炒这么高了啊
其实我觉得楼上是被老兄你给逼急了没表达清楚
我觉得的吧，作为一个struts2用户来说，我用了这个框架，按照guide一步一步的做了，你文档也没告诉我有什么隐患我该怎么预防，我正泡着妞吃火锅呢，突然间就告诉我不安全了，的确会认为是struts2的问题，毕竟我用的是struts2不是ognl，我管你struts2怎么实现的。
struts2的team可能觉得我挺冤，这是xxx的问题不是哥的错啊。。。最后就吵的不可开交了

以上桥段是不是挺熟？经典的客户vs程序员，只不过这次这个客户也是个程序员

我用了好几年struts2，前些年也看过不少struts2代码，现在早忘光了，给我留下的唯一印象就是代码质量差，其实差也无所谓，关键这开发团队半死不活的发布周期又超长，我提交的不少bug都是按照1-3年的周期来修复的，举个简单例子fileupload时候如果超大小了自定义的错误信息不显示的问题，到现在我都不知道修正了没，一直都是validateXxx里面循环一遍actionError自己检查。

鉴于struts2的这些问题，所以新项目打算换springmvc结合scala做个新的尝试
说实话struts2的模型的确很好，springmvc3之后大家基本算是平手，各有千秋吧，模型上的差异其实也就那么回事吧，看你习惯什么
至于性能，这个纯粹瞎扯了，你要是国内那几个大互联网厂商倒也罢了，问题是一堆做并发不算大的应用的程序员整天不考虑怎么提高生产力提高发布效率，却琢磨什么多个拦截器多消耗了几毫秒或者几十毫秒，你有那功夫架构做好了多上个服务器好不好一了百了……

   谢谢downpour的表扬~~。
   你指出了一个原来我没有注意到的功能变化，那就是：在级联属性绑定时，Spring 3.0允许内部的属性对象是null,而低版本的却不行。
    但是我还是要更正一个你关于Spring 3.0在级联属性绑定中的这个优化是由Spring EL带来的的错误说法。其实，级联属性绑定和Spring EL这两者没有必然联系。 Spring是这样完成数据绑定的：
   DataBinder->BeanWrapper
   具体到Spring MVC的Request的数据绑定，DataBinder的实现类是ServletRequestDataBinder。
   这个优化只是Spring 3.0优化了BeanWrapper的实现类（BeanWrapperImpl）的实现逻辑而已。BeanWrapperImpl中有一段代码专干这个活（即发现级联属性是null,自动创建一个默认的属性对象）：

	private PropertyValue createDefaultPropertyValue(PropertyTokenHolder tokens) {
		Class<?> type = getPropertyTypeDescriptor(tokens.canonicalName).getType();
		if (type == null) {
			throw new NullValueInNestedPathException(getRootClass(), this.nestedPath + tokens.canonicalName,
					"Could not determine property type for auto-growing a default value");
		}
		Object defaultValue = newValue(type, tokens.canonicalName);
		return new PropertyValue(tokens.canonicalName, defaultValue);
	}

 
 

请问楼主，例子有说明吗？我房屋test.jsp index.jsp都不行？

这个正如最近万科爆出毒地板的事情一样。谁的错？呵呵

我刚才debug了一下Spring3.1的源码，你的说法是正确的。原来我对Spring3.0在引入SpringEL的目的的理解产生了偏差。

在Spring3.0中，DataBinder的实现类有比较大的更改。当时我在扫源码时，发现了这样一段代码：

	/**
	 * Specify a Spring 3.0 ConversionService to use for converting
	 * property values, as an alternative to JavaBeans PropertyEditors.
	 */
	public void setConversionService(ConversionService conversionService) {
		Assert.state(this.conversionService == null, "DataBinder is already initialized with ConversionService");
		this.conversionService = conversionService;
		if (this.bindingResult != null && conversionService != null) {
			this.bindingResult.initConversion(conversionService);
		}
	}

因为ConversionService是SpringEL引入的一个操作接口，加上这段注释的说明，我就误以为在DataBinder中引入ConversionService的目的是代替原始的PropertyEditors来完成对JavaBean的设置。

在我调试了源码之后，发现在整个数据绑定的过程中，ConversionService并没有起到决定性作用，它内部的实现使用的是一个递归调用BeanWrapperImpl的方式。在每次绑定的时候，ConversionService只起到了一个类型转化的作用。

这实在比较坑爹啊！因为无论从注释还是从引入的版本来看，Spring似乎都想利用SpringEL来做一番文章，不过它却没有这么做！我被骗了！

这也充分证明了我不够严谨的态度，仅仅凭借注释的解释和过往的经验就判断整个机制的方向性变化。这个教训需要吸取！在此需要向stamen道歉。

   Spring的整个体系很庞大，细节认识的偏差在所难免，我也从和你的交流中学习了很多！多多交流！
  

   应该是你工程项目配置的问题吧（我是使用Idea的），例子是没有问题的，我每个都有走测试用例。

谢谢分享、提供！