程式師世界 >> 編程語言 >> JAVA編程 >> 關於JAVA >> SSH框架網上商城項目第24戰之Struts2中處置多個Model要求的辦法

SSH框架網上商城項目第24戰之Struts2中處置多個Model要求的辦法

編輯：關於JAVA

SSH框架網上商城項目第24戰之Struts2中處置多個Model要求的辦法。本站提示廣大學習愛好者：（SSH框架網上商城項目第24戰之Struts2中處置多個Model要求的辦法）文章只能為提供參考，不一定能成為您想要的結果。以下是SSH框架網上商城項目第24戰之Struts2中處置多個Model要求的辦法正文

1. 成績的提出

　　Struts2中假如完成了ModelDriven<model>接口便可以將傳來的參數注入到model中了，便可以在Action中應用該model，然則假如如今有兩個model都須要在統一個Action中應用該咋整呢？好比上一節我們完成了在線付出功效，然則付出完成了還沒停止，我們須要吸收從第三方那裡反應回來的信息，好比勝利付出後，我們須要給付款方發送郵件和短信等。所以我們還須要在payAction中獲得從第三方傳過去的參數，因為從第三方傳過去的參數與我們傳曩昔的參數是分歧的，所以吸收那些參數我們也得寫一個Model（BackData），那末成績來了，我們的PayAction曾經寫成如許子了：public class PayAction extends BaseAction<SendData>，即曾經在BaseAction中完成了ModelDriven<SendData>接口了，那末若何在一個action中再吸收一個Model，而且還得對它們停止分歧的處置呢？
　　有種處理方法（其實也不克不及稱為處理方法……由於基本就沒處理……）就是寫一個Model，然後讓SendData和BackData繼續它，然則成績是這兩個Model基本就沒緊要，為啥要繼續統一個Model，所以這類處理方法現實上是在押避下面的成績。
　　在SpringMVC（SpringMVC還沒真正開端學，假如有說錯，請斧正！）很好的處理了這個成績，由於SpringMVC中每一個辦法對應一個Model，而不是每一個Action對應一個Model，這就便利了，我在統一個Action中寫兩個辦法便可，分歧的辦法處置分歧的Model。

2. 成績的處理

　　針對這個成績，Struts2也供給了一種處理方法：
　 Struts2在ActionContext中存儲了許多個Map，好比之條件到的request, session, application等，個中還有個parameterMap，該Map中存儲了request一切的要求參數，只需我們的Action完成了parameterAware接口，就可以拿到這個parameterMap，這就跟ModelDriven的事理是一樣的，假如我們完成了ModelDriven<Model>接口，那末我們在Action中就可以取得該Model，即界說一個Model並完成set辦法便可。
　好了，那如今成績好辦了，付出的參數和前往的參數是分歧的，也就是說兩次進入PayAcition中的參數是分歧的，即兩次的parameterMap中裝的數據紛歧樣，那只需我們在Action當選取一個參數（該參數只需能辨別兩次是分歧的request要求便可）作為斷定，就曉得以後該用哪一個Model來吸收參數（SendData照樣BackData）。上面我們改寫一下PayAction中的代碼：

@Controller("payAction")
@Scope("prototype")
public class PayAction extends BaseAction<Object> implements ParameterAware {
//留意下面繼續的BaseAction中不克不及寫SendData了，要寫Object，等下我們再斷定詳細應用哪一個 

 //界說一個Map吸收request的要求參數
 private Map<String, String[]> parameters;
 @Override
 public void setParameters(Map<String, String[]> parameters) {
  this.parameters = parameters;

 } 
 /*在struts-default.xml文中，ServletConfig攔阻器在ModelDriven之前先履行，所以我們在注入model的時刻，
 request參數曾經有了，如許我們便可以在getModel()辦法中經由過程參數來斷定是哪一個要求了*/
 @Override
 public Object getModel() {
 //付款的時刻有付出通道編碼的參數(pd_FrpId)，前往的時刻沒有
 //如許我們便可以經由過程該參數斷定是付出照樣前往了
  if(parameters.get("pd_FrpId") != null) {
   model = new SendData();
  } else {
   model = new BackData();
  }
  return model;
 }

 //向易寶發送數據的辦法
 public String goBank() {
  //對應發送的model：SendData
  SendData sendData = (SendData)model;
  //處置發送數據的邏輯，前一節曾經完成過了……
 }

 //吸收前往的數據的辦法
 public void backBank() {
  //對應吸收的model：BackData
  BackData backData = (BackData)model;
  //處置前往數據的邏輯……前面再來完成，
  //先講Struts2處置多個Model要求這個常識點
 }
}

3. Struts2的處置流程

　　我們再來剖析一下Struts2的履行流程，如許加倍利於懂得下面的道理。Struts處置流程：

1）、獲得要求後，先創立Action的署理，在創立署理的時刻趁便創立了Action；
2）、履行18個攔阻器，攔阻器履行勝利後再挪用Action的辦法；
3）、Action的辦法履行終了後，再挪用18個攔阻器
所以依據這個流程，我們曉得：先創立Action–>再履行攔阻器（先履行ServletConfig，再履行ModelDriven，由於ServletConfig攔阻器配在ModelDriven的後面）。所以在下面的代碼中，我們才可以在getModel()辦法中去拿parameterMap中的數據來停止斷定。　　
　　用上面簡略的時序圖來直不雅的表現一下下面的處置流程吧：

這就很直不雅的看出Struts2的處置流程了，那末關於下面處置多個Model要求也很好懂得了。到這裡，Struts2處置多個Model要求的辦法部門曾經剖析完了，上面針對本項目中的一個小邏輯，做一下完美。

4. 完美吸收數據的辦法

　　下面遺留了一個邏輯的完成，即處置前往的數據，這裡的邏輯重要有：更新定單狀況（已付款，已發貨等），發送郵件，發送短信等。我們先把更新定單狀況完成，主語發送郵件和發送短信的功效，我們前面再寫。
先完美backBank()辦法：

public void backBank() {
 BackData backData = (BackData)model;
 System.out.println(model);
 boolean isOK = payService.checkBackData(backData);
 if(isOK) {
  //1. 更新定單狀況,參數是本身依據數據庫中的情形傳出來的，用來測試
  forderService.updateStatusById(Integer.valueOf(201605006), 2);
  //2. 依據user郵箱地址，發送郵件
  //3. 發送手機短信
  System.out.println("----success!!----");
 } else {
  System.out.println("----false!!!----");
 }
}

然後我們完成payService中的checkBackData(backData)辦法（邏輯和21節中的根本一樣）：

@Service("payService")
public class PayServiceImpl implements PayService {
  //省略不相干代碼
  /******************************下面是發送要求的辦法**************************************/
  // 完成前往數據的追加
  private String joinBackDataParam(BackData backData) {
   // 追加字符串,為加密驗證做預備
   StringBuffer infoBuffer = new StringBuffer();
   infoBuffer.append(backData.getP1_MerId());
   infoBuffer.append(backData.getR0_Cmd());
   infoBuffer.append(backData.getR1_Code());
   infoBuffer.append(backData.getR2_TrxId());
   infoBuffer.append(backData.getR3_Amt());
   infoBuffer.append(backData.getR4_Cur());
   infoBuffer.append(backData.getR5_Pid());
   infoBuffer.append(backData.getR6_Order());
   infoBuffer.append(backData.getR7_Uid());
   infoBuffer.append(backData.getR8_MP());
   infoBuffer.append(backData.getR9_BType());
   return infoBuffer.toString();
  }

  // 對前往來的數據停止加密,而且和傳過去的密文停止比擬,假如OK則解釋數據沒有被改動
  public boolean checkBackData(BackData backData){
   String joinParam=this.joinBackDataParam(backData);
   // 加密後獲得本身的密文
   String md5 = DigestUtil.hmacSign(joinParam.toString(),key);
   // 密文和傳過去密文比擬
   return md5.equals(backData.getHmac());
  } 
}

最初我們完成ForderService中的updateStatusById辦法：

//ForderService接口
public interface ForderService extends BaseService<Forder> {
 //省略其他有關代碼……
 //依據定單編號，更新定單狀況
 public void updateStatusById(int id, int sid);
}

//ForderServiceImpl完成類
@Service("forderService")
public class ForderServiceImpl extends BaseServiceImpl<Forder> implements ForderService {

 //省略其他有關代碼

 @Override
 public void updateStatusById(int id, int sid) {
  String hql = "update Forder f set f.status.id=:sid where f.id=:id";
  getSession().createQuery(hql)
   .setInteger("sid", sid)
   .setInteger("id", id)
   .executeUpdate();
 } 
}

　　如許就可以在顧客付款後更新定單狀況了。

原文鏈接：http://blog.csdn.net/eson_15/article/details/51465067

以上就是本文的全體內容，願望對年夜家的進修有所贊助，也願望年夜家多多支撐。