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，封裝機制更為智能，代碼會簡化很多。