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

?