springMVC数据封装成POJO

springMVC把前台的数据封装为POJO与struts2的封装形式不同。struts2需要在控制器声明需封装的POJO，而springMVC不需要任何准备工作，只需在相应的方法的参数中加上需封装的POJO，当用户提交表单时，springMVC会根据表单中dom元素的name属性与请求的方法中的参数中的POJO的属性名进行比对，如果相同，则将name属性的值赋给这个属性，进而完成封装，下面举例说明：

一、先看一下定义的POJO

Orders(订单)

/**
 * 订单
 * @author Administrator
 *
 */
public class Orders implements Serializable {
    private String oid;//订单id
    
    private Opportunity  opportunity;//销售机会 
    private Linkman linkman;//联系人 
    private User user;//业务员 
    
    private Date bdate; //开单日期
    private Date fdate;//合同到期时间
    private Float ysprice;//应收金额
    private int statues;//审核状态
    private Integer flag;//订单状态 
    private String remark;//备注
    private Integer uids;//订单审核人
}

上面的Orders类中有一个Opportunity属性（销售机会），属性名为opportunity，下面是定义的Opportunity类：

Opportunity（销售机会）（注：Orders与Opportunity呈一对一关联）

/**
 * 销售机会
 * @author Administrator
 *
 */
public class Opportunity implements Serializable{
    private int opid;
    private Float allprice;//所有商品的购买总价
    private int allcount;//所有商品的购买数量
    private String odate;//下单时间
    
    private User user;//业务员
    private Linkman linkman;//联系人
    
}

二、再看一下提交的jsp相关片段

三、上面的表单的请求地址是${pageContext.request.contextPath}/addOrder，我们来看一下这个方法的定义：

当用户提交表单后，springMVC会找到这个方法，然后将表单中的name为opportunity对应的值赋给这个方法中Orders类中实例引用名orders的opportunity属性，通过debug调试，可以印证这一点：

可以看出，对应表单中的name="opportunity.linkman.lname"对应的值，springMVC是先将此值赋给Opportunity类中的linkman属性，再将opportunity的值赋给addOrder方法中参数Orders中的opportunity属性，即完成了对其引用名orders的封装。

四、如果将表单、请求方法修改成以下的情况，那又会如何呢？

还是bug调试，看一下执行addOrder方法时的情况：

以上的结果表明表单提交后，springMVC并没有为addOrder方法参数中的Orders封装opportunity这个属性，这是因为表单中根本找不到这个属性，何谈封装呢？但表单中有opid和linkman.lname这两个属性，且在addOrder方法中有Opportunity opp这个参数，在Opportunity 类中有opid、linkman这个两个属性，因此springMVC会将表单中的opid和linkman.lname这两个属性的值赋给参数中的Opportunity opp的opid、linkman这两个属性，从而进行封装。

后记：springMVC相比于struts2，封装机制更为智能，代码会简化很多。