1. Problemaufzucht
Wenn in Struts2 die Schnittstelle modeldelen <modell> implementiert ist, können die übergebenen Parameter in das Modell injiziert werden und das Modell kann in der Aktion verwendet werden. Was sollte ich jedoch tun, wenn zwei Modelle in derselben Aktion verwendet werden müssen? Im vorherigen Abschnitt haben wir beispielsweise die Online -Zahlungsfunktion abgeschlossen, die Zahlung ist jedoch noch nicht beendet. Wir müssen Informationsfeedback von Dritten erhalten. Nach erfolgreicher Zahlung müssen wir beispielsweise E -Mails und Textnachrichten an den Zahler senden. Daher müssen wir auch die Parameter erhalten, die der Dritte in der Zahlung übergeben. Da sich die von den Dritten übergingenden Parametern von denen unterscheiden, müssen wir ein Modell (Backdata) schreiben, um diese Parameter zu erhalten. Das Problem ist also, dass unsere Zahlung wie folgt geschrieben wurde: Die öffentliche Klassenzahlung erweitert die Basisreaktion <SendData>, dh die modelldelen <SendData> -Schinschnittstelle wurde in der Basiswirkung implementiert. Wie erhalten wir also ein anderes Modell in einer Aktion und müssen sie anders umgehen?
Es gibt eine Lösung (tatsächlich kann sie nicht als Lösung bezeichnet werden ... weil sie überhaupt nicht gelöst wurde ...), ein Modell zu schreiben und SendData und Backdata zu erben, aber das Problem ist, dass diese beiden Modelle überhaupt nichts damit zu tun haben. Warum müssen wir dasselbe Modell erben? Diese Lösung entgeht also tatsächlich dem obigen Problem.
Dieses Problem ist in SpringMVC gut gelöst (SpringMVC hat nicht wirklich begonnen zu lernen. Wenn Sie etwas falsches sagen, korrigieren Sie es bitte!), Da jede Methode in SpringMVC einem Modell entspricht, anstatt dass jede Aktion einem Modell entspricht, das bequem ist. Ich kann nur zwei Methoden in dieselbe Aktion schreiben und verschiedene Methoden befassen sich mit verschiedenen Modellen.
2. Lösung für das Problem
Struts2 bietet auch eine Lösung für dieses Problem:
Struts2 speichert viele Karten im ActionContext, z. B. die zuvor erwähnte Anfrage, Sitzung, Bewerbung usw. Es gibt auch eine Parametermap, in der alle Anforderungsparameter der Anforderung gespeichert werden. Solange unsere Aktion die Parameteraware -Schnittstelle implementiert, können wir diese Parametermap erhalten. Dies ist das gleiche wie modeldiven. Wenn wir die modelldelen <modell> -Rumentation implementieren, können wir das Modell in der Aktion erhalten, dh ein Modell definieren und die SET -Methode implementieren.
Okay, jetzt ist das Problem leicht zu lösen. Die Zahlungsparameter und die zurückgegebenen Parameter sind unterschiedlich. Das heißt, die Parameter, die die Payacition zweimal eingeben, sind unterschiedlich, dh die in der Parametermap installierten Daten sind zweimal unterschiedlich. Solange wir einen Parameter in der Aktion auswählen (der Parameter kann von den beiden verschiedenen Anforderungsanfragen unterschieden werden), wissen wir, welches Modell die Parameter (sendData oder backdata) empfangen sollte. Schreiben wir den Code in der Zahlung um:
@Controller ("PayAction")@scope ("Prototyp") öffentliche Klassenzahlung erweitert Baseaction <FORGANCE> implementiert Parameteraware {// Beachten Sie, dass SendData nicht in der oben geerbten Baseaction geschrieben werden kann. Sie müssen Objekt schreiben. Später bestimmen wir, welche sie verwenden sollen // eine Karte definieren, um eine private Map <String []>> Parameter von Anforderungen zu empfangen. @Override public void setParameters (MAP <String, String []> Parameter) {this.parameters = parameter; } / *In dem Artikel von Struts-Default.xml wird der ServletConfig-Interceptor vor modeldelen ausgeführt. Wenn wir also das Modell injizieren, ist der Anforderungsparameter bereits verfügbar, sodass wir Parameter in der GetModel () -Methode verwenden können, um zu bestimmen, welche Anforderung mit Parametern verwendet wird. Nicht zurückgeben // Auf diese Weise können wir diesen Parameter verwenden, um festzustellen, ob er bezahlt oder zurückgegeben wird, wenn (parameter.get ("pd_frpid")! = null) {model = new sendData (); } else {model = new BackData (); } Rückgabemodell; } // Methode zum Senden von Daten an yibao public String gobank () {// Das entsprechende gesendete Modell: sendData sendData sendData = (sendData) Modell; // Die Logik des Sendens von Daten wurde im vorherigen Abschnitt implementiert ...} // Die Methode zum Empfangen der zurückgegebenen Daten public void backbank () {// Das entsprechende empfangene Modell: Backdata Backdata BackData = (Backdata) Modell; // Die Logik des Umgangs mit zurückgegebenen Daten ... sie wird später implementiert, // Der Wissenspunkt von Struts2 erster Handles mehrere Modellanforderungen}}}}3.. Struts2 Verarbeitungsfluss
Lassen Sie uns den Ausführungsprozess von Struts2 analysieren, der dem Verständnis der oben genannten Prinzipien förderlicher ist. Streben -Verarbeitungsfluss:
1) Erstellen Sie nach Erhalt der Anforderung zuerst den Proxy der Aktion und erstellen Sie dann die Aktion beim Erstellen des Proxy.
2) 18 Interceptors ausführen und dann die Aktionsmethode aufrufen, nachdem der Interceptor erfolgreich ausgeführt wurde.
3) Nach der Ausführung der Aktionsmethode werden 18 Interceptors aufgerufen. Nach diesem Prozess wissen wir also: Aktion> und dann den Interceptor ausführen (zuerst ServletConfig ausführen und dann modelldurchführen ausführen, da der ServletConfig -Interceptor vor modelDriven ausgestattet ist). Im obigen Code können wir die Daten in Parametermap in der Methode getModel () verwenden, um Urteile zu fällen.
Verwenden Sie das folgende einfache Timing -Diagramm, um den obigen Verarbeitungsfluss intuitiv darzustellen:
Dies zeigt den Verarbeitungsfluss von Struts2 -Intuition, sodass die obigen Verarbeitung mehrerer Modellanforderungen leicht verstehen kann. Zu diesem Zeitpunkt wurde der Teil der Methode von Struts2 zur Verarbeitung mehrerer Modellanforderungen analysiert. Das Folgende ist eine kleine Logik in diesem Projekt.
4. Verbessern Sie die Methode zum Empfangen von Daten
Eine Logik dahinter ist die Implementierung der Logik, dh die Verarbeitung der zurückgegebenen Daten. Die Logik hier enthält hauptsächlich: Aktualisieren des Bestellstatus (bezahlt, versendet usw.), Senden von E -Mails, Senden von Textnachrichten usw. Wir werden zunächst den Update -Bestellstatus abschließen, E -Mails senden und Textnachrichten an den Betreff senden. Wir schreiben sie später.
Verbessern Sie zuerst die Backbank () -Methode:
public void backbank () {backdata backdata = (backdata) Modell; System.out.println (Modell); boolean isok = payService.CheckbackData (Backdata); if (isok) {// 1. Aktualisieren Sie den Bestellstatus, die Parameter werden entsprechend der Situation in der Datenbank übertragen, mit der FerderService.UpdatestatusById (Integer.ValueOf (201605006), 2) verwendet wird. // 2. Senden Sie eine E -Mail gemäß der Benutzer -E -Mail -Adresse // 3. Senden Sie ein Mobiltelefon-Textnachrichtssystem.out.println ("---- Erfolg !! -----"); } else {System.out.println ("---- false !!! -----"); }}Anschließend vervollständigen wir die Methode von CheckbackData (Backdata) in PayService (die Logik ist im Grunde genommen die gleiche wie in Abschnitt 21):
@Service ("PayService") öffentliche Klasse PayServiceImpl Implements PayService {// irrelevante Code weglassen/************************************************************************** backdata) {// append String, um die Verschlüsselungsüberprüfung StringBuffer Infobuffer = new StringBuffer () vorzubereiten; 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 (); } // Verschlüsseln Sie die zurückgegebenen Daten und vergleichen Sie sie mit dem übergesandten Chiffretext. Wenn OK, bedeutet dies, dass die Daten nicht manipuliert wurden. public boolean checkbackData (Backdata backdata) {String joins -Param = this.joinbackDataparam (Backdata); // Holen Sie sich Ihren eigenen CipherText String md5 = digestUtil.hmacSign (joinParam.toString (), Schlüssel); // Vergleich von CipheText mit dem Ciphertext über Return MD5.Equals (Backdata.Gethmac ()); }}Schließlich vervollständigen wir die UpdateStatusById -Methode in Ferderservice:
// FORDERService Interface Public Interface FderderService erweitert BaseService <Fder> {// andere nicht verwandte Codes auslassen ... // den Bestellstatus gemäß der Bestellnummer public void updatestatususById (int id, int SID);} // FREDERSIMIMPLEMPLEMPLEGENDE BAGSISVISIVISIVISIVISIVISIVISIVISIVICISIVICISIVICEL ("FORDERDERVISIMICE"). implementiert fderderService {// andere nicht verwandte Codes @Override public void updatestatusById (int id, int sid) {string hql = "aktualisieren fder f set f.status.id =: sid wobei f.id =: id"; GetSession (). CreateEquery (HQL) .setInteger ("Sid", SID) .SetInteger ("ID", ID) .executeUpdate (); }}Auf diese Weise kann der Bestellstatus aktualisiert werden, nachdem der Kunde bezahlt wird.
Original -Link: http://blog.csdn.net/eson_15/article/details/51465067
Das obige ist der gesamte Inhalt dieses Artikels. Ich hoffe, es wird für das Lernen aller hilfreich sein und ich hoffe, jeder wird Wulin.com mehr unterstützen.