springMVC把前台的数据封装为POJO与struts2的封装形式不同。struts2需要在控制器声明需封装的POJO，而springMVC不需要任何准备工作，只需在相应的方法的参数中加上需封装的POJO，当用户提交表单时，springMVC会根据表单中dom元素的name属性与请求的方法中的参数中的POJO的属性名进行比对，如果相同，则将name属性的值赋给这个属性，进而完成封装，下面举例说明：
一、先看一下定义的POJO
Orders(订单)
/*** 订单* @author Administrator**/ public class Orders implements Serializable {private String oid;//订单idprivate 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，封装机制更为智能，代码会简化很多。
