1. Risser des problèmes
Dans Struts2, si l'interface <mode-modèle> modèle est implémentée, les paramètres passés peuvent être injectés dans le modèle, et le modèle peut être utilisé dans l'action, mais que dois-je faire s'il existe deux modèles qui doivent être utilisés dans la même action? Par exemple, dans la section précédente, nous avons rempli la fonction de paiement en ligne, mais le paiement n'a pas encore pris fin. Nous devons recevoir des commentaires d'informations de tiers. Par exemple, après un paiement réussi, nous devons envoyer des e-mails et des SMS au payeur. Nous devons donc également obtenir les paramètres adoptés par le tiers de la PayAction. Étant donné que les paramètres passés du tiers sont différents de ceux qui nous sont passés, nous devons écrire un modèle (backdata) pour recevoir ces paramètres. Le problème est donc que notre PayAction a été écrit comme suit: la classe publique PayAction étend BaseAction <endData>, c'est-à-dire que l'interface ModelDriven <endData> a été mise en œuvre dans la réaction de base. Alors, comment recevons-nous un autre modèle dans une action et devons-nous les gérer différemment?
Il y a une solution (en fait, il ne peut pas être appelé une solution ... car il n'a pas été résolu du tout ...) qui est d'écrire un modèle et de laisser Senddata et Backdata l'hériter, mais le problème est que ces deux modèles n'ont rien à voir avec cela. Pourquoi devons-nous hériter du même modèle? Cette solution échappe donc en fait au problème ci-dessus.
Ce problème est bien résolu dans SpringMVC (SpringMVC n'a pas vraiment commencé à apprendre. Si vous dites quelque chose de mal, veuillez le corriger!) Parce que chaque méthode de SpringMVC correspond à un modèle, plutôt que chaque action correspond à un modèle, ce qui est pratique. Je peux simplement écrire deux méthodes dans la même action, et différentes méthodes traitent de différents modèles.
2. Solution au problème
Struts2 fournit également une solution à ce problème:
Struts2 stocke de nombreuses cartes dans l'actionContext, telles que la demande, la session, l'application, etc. mentionnées précédemment. Il existe également un paramètre, qui stocke tous les paramètres de demande de la demande. Tant que notre action implémente l'interface paramètreware, nous pouvons obtenir ce paramètre. C'est la même chose que ModelDriven. Si nous implémentons l'interface <mode-modèle> ModelDriven, nous pouvons obtenir le modèle dans l'action, c'est-à-dire définir un modèle et implémenter la méthode SET.
D'accord, maintenant le problème est facile à résoudre. Les paramètres de paiement et les paramètres retournés sont différents. C'est-à-dire que les paramètres qui entrent deux fois par la Payacition sont différents, c'est-à-dire que les données installées dans le paramètre deux fois sont différentes. Tant que nous sélectionnons un paramètre dans l'action (le paramètre peut être distingué des deux demandes de demande différentes) en jugement, nous saurons quel modèle doit être utilisé pour recevoir les paramètres (SendData ou Backdata). Réécrivons le code dans PayAction:
@Controller ("PayAction") @ Scope ("Prototype") La classe publique PayAction étend Baseaction <objet> implémente ParameterAware {// Remarque que SendData ne peut pas être écrit dans la réaction de base héritée ci-dessus. Vous devez écrire un objet. Plus tard, nous déterminerons lesquels utiliser // définir une carte pour recevoir la demande de carte privée <String, String []> Paramètres; @Override public void setParameters (map <string, string []> Paramètres) {this.parameters = paramètres; } / * Dans l'article Struts-Default.xml, l'interceptor ServletConfig est exécuté avant le modèle, donc lorsque nous injectons le modèle, le paramètre de demande est déjà disponible, afin que nous puissions utiliser des paramètres dans la méthode GetModel () pour déterminer la demande est utilisée par les paramètres * / @Override Object GetModel () {// Il y a un paramètre codé par le canal de paie ne revient pas // de cette façon, nous pouvons utiliser ce paramètre pour déterminer s'il est payé ou renvoyé si (paramètres.get ("pd_frpid")! = null) {Model = new SendData (); } else {Model = new Backdata (); } Retour Modèle; } // Méthode pour l'envoi de données à Yibao public String gobank () {// Le modèle envoyé correspondant: SendData sendData sendData = (sendData) modèle; // La logique de l'envoi de données a été implémentée dans la section précédente ...} // La méthode de réception de données renvoyées publiques void backbank () {// le modèle de modèle reçu: backdata backdata backdata = (backdata) du modèle; // La logique de la gestion des données renvoyées ... elle sera implémentée plus tard, // le point de connaissance de Struts2 premiers gère plusieurs demandes de modèle}}}3. Flux de traitement de Struts2
Analysons le processus d'exécution de Struts2, qui sera plus propice à la compréhension des principes ci-dessus. Struts Traitement Flux:
1) Après avoir obtenu la demande, créez d'abord le proxy de l'action, puis créez l'action lors de la création du proxy;
2) Exécutez 18 intercepteurs, puis appelez la méthode d'action une fois l'intercepteur exécuté avec succès;
3) Une fois la méthode d'action exécutée, 18 intercepteurs sont appelés. Ainsi, selon ce processus, nous savons: Créer une action> puis exécuter l'intercepteur (exécuter d'abord ServletConfig, puis exécuter ModelDriven, car l'intercepteur ServletConfig est équipé devant ModelDriven). Ainsi, dans le code ci-dessus, nous pouvons utiliser les données dans Paramettermap dans la méthode getModel () pour porter des jugements.
Utilisez le schéma de synchronisation simple suivant pour représenter intuitivement le flux de traitement ci-dessus:
Cela montre le flux de traitement de l'intuition Struts2, il est donc facile de comprendre les demandes de modèle multiple de traitement ci-dessus. À ce stade, la partie de la méthode de Struts2 pour gérer plusieurs demandes de modèle a été analysée. Ce qui suit est une petite logique dans ce projet.
4. Améliorer la méthode de réception des données
Une logique derrière cela est l'implémentation de la logique, c'est-à-dire le traitement des données renvoyées. La logique ici comprend principalement: la mise à jour de l'état de la commande (payé, expédié, etc.), l'envoi d'e-mails, l'envoi de messages texte, etc. Nous terminerons d'abord l'état de la commande, envoyez des e-mails et envoyez des SMS au sujet, et nous l'écrire plus tard.
Améliorez d'abord la méthode Backbank ():
public void backbank () {backdata backdata = (backdata) modèle; System.out.println (modèle); booléen isok = payservice.checkbackData (backdata); if (isOK) {// 1. Mettez à jour l'état de la commande, les paramètres sont transmis en fonction de la situation dans la base de données, utilisés pour tester Forderservice.UpDateStatusByid (Integer.Valueof (201605006), 2); // 2. Envoyez un e-mail en fonction de l'adresse e-mail de l'utilisateur // 3. Envoyer un Système de SMS de téléphone mobile.out.println ("---- Succès !! -----"); } else {System.out.println ("---- false !!! -----"); }}Ensuite, nous terminons la méthode CheckBackData (Backdata) dans le paiement (la logique est fondamentalement la même que dans la section 21):
@Service ("payservice") Classe publique PayserviceImpl implémente payservice {// omettre le code non pertinent / *******************************************. backdata) {// APPEND String pour se préparer à la vérification de chiffrement 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 (); } // Cryptez les données renvoyées et comparez-les avec le texte chiffré envoyé. Si OK, cela signifie que les données n'ont pas été falsifiées. public boolean checkBackData (backdata backdata) {string joinParam = this.joinbackDataparam (backdata); // Obtenez votre propre chaîne CipherText md5 = digestUtil.hmacsign (joinParam.toString (), key); // Comparaison du texte chiffré avec le texte chiffré envoyé sur retour md5.equals (backdata.gethmac ()); }}Enfin, nous terminons la méthode UpdateStatusById dans Forderservice:
// Interface Forderservice Interface publique Forderservice étend BasEservice <Neder> {// omettre d'autres codes non liés ... // Mettez à jour l'état de la commande en fonction du numéro de commande public void updateStatusById (int id, int sid);} // ForderserviceImpl Class de mise en œuvre @service ("Forderservice") Classe publique implémente Forderservice {// omettre d'autres codes non liés @Override public void updateStatusById (int id, int sid) {String hql = "Update FORDER F set f.status.id =: sid où f.id =: id"; getSession (). CreateQuery (HQL) .SetInteger ("Sid", Sid) .SetInteger ("id", id) .ExECuteUpdate (); }}Cela permettra à la mise à jour de l'état de commande une fois le client payé.
Lien original: http://blog.csdn.net/eson_15/article/details/51465067
Ce qui précède est tout le contenu de cet article. J'espère que cela sera utile à l'apprentissage de tous et j'espère que tout le monde soutiendra davantage Wulin.com.