Il y a deux problèmes restants dans le panier d'achat, à savoir le stockage en cascade des informations de commande et le cache de page. Les informations ici se réfèrent au panier et aux articles de magasinage. Autrement dit, lorsque nous stockons les informations du panier d'achat dans la base de données, nous stockons également les informations de chaque article d'achat, et les clés étrangères sont liées, ce qui implique le problème de stockage en cascade en hibernate; Le problème du cache de page fait référence au moment où l'utilisateur confirme la commande, s'il clique en arrière, il reviendra à la page de confirmation de commande. La page de confirmation de commande sort à l'heure actuelle, et la session est toujours là, et les informations sont toujours les informations tout à l'heure. Ce n'est évidemment pas le résultat que nous voulons, et nous l'analyserons un par un plus tard. Cette section traite principalement des stocks en cascade d'informations sur l'ordre et de la mise en cache des pages.
1. Le stockage en cascade des informations de commande
Le stockage en cascade de deux tables connexes dans Hibernate doit être configuré. Ici, nous introduisons principalement la méthode de configuration des annotations. Le pojo de l'ordre est Frander, le pojo de l'article de shopping est Sorder, et le Frander et le Sorder sont des relations individuelles. Tout d'abord, définissons leur configuration d'annotation, comme suit:
@Entity public class FORDER implémente java.io.serializable {// omettre le code non pertinent ... Liste privée <Sorder> SOORDERS = new ArrayList <Sorder> (); @Onetomany (Cascade = CascadeType.all, fetch = fetchType.lazy, maptedBy = "FORDER") public list <sorder> getsorders () {return this.sorders; } public void setSorders (list <sorder> SOORDERS) {this.sorders = SOORDERS; }} @Entity public class Sorder implémente java.io.serializable {// omettre le code non pertinent ... private fourder fourder; @ManyToOne (fetch = fetchType.lazy) @joincumn (name = "fid") public Ford GetForder () {return this.Forder; } public void setForder (fourder sterder) {this.Forder = fourder; }} Après cette configuration, lorsque nous enregistrons des éléments de ligne, nous enregistrerons également les articles d'achat et associerons automatiquement les clés étrangères. Mais la prémisse est que nous devons définir la relation entre eux, c'est-à-dire SetSorders () dans le fourder, setForder () dans le Soorder et les propriétés des entités correspondant à d'autres clés étrangères connexes.
Avant, lorsque nous avons ajouté l'article d'achat au panier, FORDER.SETSORD (SORDER) a été exécuté. Nous devons maintenant ajouter Frander au Soorder, nous l'ajoutons donc au code d'origine, comme suit:
// Ceci est le code de la section 17. Nous insérons une phrase dans le milieu @Service ("Sorderservice") Public Class SorderserviceImpl étend BaseServiceImpl <Sorder> implémente Sorderservice {@Override Public Ford AddSorder (Ford Frander, Product Product) {Boolean Ishave = false; // Utilisé pour marquer s'il existe des articles d'achat en double // Obtenez l'article d'achat actuel SORDER SOORDER = ProductToSorder (produit); // jugez si l'article d'achat actuel est dupliqué. S'il est dupliqué, ajoutez la quantité pour (Sorder Old: fourder.getSorders ()) {if (old.getProduct (). GetId (). Equals (Sorder.getProduct (). GetId ())) {// Il y a des doublures pour les articles de shopping, ajoutez la quantité old.setNumber (old.getNumber () + Soorder.getNumber (Ajouter la quantité); isHave = true; casser; }} // L'article d'achat actuel n'existe pas dans le panier, if (! Ishave) {// Nous insérons une phrase ici: // avant d'ajouter l'article d'achat à l'article d'achat, établissons d'abord l'association entre l'article d'achat et le panier, mais à ce moment-là, vous entrez d'abord le chanteur de Warehit, vous entrez dans le ware house-shopping. À ce moment-là, il y a la clé principale SOORDER.SetForder (FORDER); fourder.getSorders (). Add (Sorder); } return stand; } @Override public Sorder ProductToSorder (produit produit) {Sorder Soorder = new Sorder (); Soorder.SetName (Product.GetName ()); Soorder.setNumber (1); Soorder.SetPrice (Product.GetPrice ()); Soorder.setProduct (produit); retourner Sorder; }}Ok, jetons un coup d'œil à quelle action à sauter lorsque la commande confirme:
Nous allons donc compléter la logique dans la Franderaction:
@Controller ("FORDERACTION") @Scope ("Prototype") Public Class ForderAction étend Baseaction <Ford> {@Override public Ford GetModel () {Model = (FORDER) Session.get ("FORDER"); modèle de retour; } // Implémentez la fonction de stockage en cascade du panier d'achat (commande) et des articles d'achat (articles de ligne) public public Save () {// // remettez les articles d'achat de la session à l'objet du modèle actuel // FORDER FORDER = (FORDER) Session.get ("FORDER"); // //model.setsorders (fourder.getSorders ()); //Forder.SetAddress (Model.getAddress ()); //Forder.SetName (Model.GetName ()); //Forder.SetPhone (Model.Getphone ()); //Forder.SetRemark (Model.getRemark ()); //Forder.SetUser((User)Session.get("User ")); //Forder.setStatus(New Status (1)); //Forder.SetPost (Model.GetPost ()); //Forder.SetPost (Model.GetPost ()); //Forder.SetUser((User)Session.get("User ")); //Forder.setStatus(New Status (1)); //Forder.SetPost (Model.GetPost ()); // // Bibliothèque en cascade (doit être configurée dans l'annotation de XML ou POJO), de sorte que le fourder d'association Soorder est requis // // ajouter à la classe SorderserviceIMPL.SetForder (fourder); //Forderservice.save(Forder); Model.SetUser ((utilisateur) session.get ("utilisateur")); Model.SetStatus (nouveau statut (1)); FORDERSERVICE.SAVE (modèle); retourner "banque"; }} Comme on peut le voir à partir du code ci-dessus, il existe deux méthodes: le premier ne suit pas la méthode GetModel (la partie que j'ai commentée). Cette méthode est assez stupide. Étant donné que FranderAction hérite de BaseAction et BaseAction met en œuvre l'interface modélisée, les données passées seront encapsulées dans le modèle. Le modèle est une propriété dans Baseaction. Ensuite, nous devons transmettre toutes les informations du modèle au Frander de la session, puis les données du Frander peuvent être en cascade avec Sorder pour entrer la bibliothèque. Cependant, cette méthode est un peu stupide ... donc nous utilisons la deuxième méthode, réécrivons la méthode GetModel et attribuons directement le fourder au modèle, puis nous devons simplement ajouter les éléments en cascade dans le modèle, c'est-à-dire le code non annoté ci-dessus. De cette façon, après que l'utilisateur clique pour confirmer la commande, les informations seront entrées dans la base de données et passent à la page de paiement (la page de paiement doit être effectuée ensuite, afin que vous puissiez simplement passer à un JSP en premier).
2. Page Problèmes de mise en cache
Maintenant, l'entrée en cascade des informations de commande a été résolue, mais si l'utilisateur clique pour confirmer la commande, puis, nous constatons qu'il s'agit toujours de la page de confirmation de commande d'origine, et les informations sont toujours les informations tout à l'heure, et la session n'est pas close, ce qui signifie que je dois confirmer les informations de commande, ce qui est évidemment inapproprié. En d'autres termes, lorsque l'utilisateur clique pour confirmer l'ordre, nous ne pouvons pas laisser le cache de page. De cette façon, lorsque l'utilisateur clique pour soutenir, il montrera que la page a expiré, et nous l'avons simplement laissé passer à la page d'accueil.
Nous savons que la page JSP frontale peut être définie afin que le navigateur ne cache pas de données, nous pouvons donc le définir comme suit sur la page Front-end Confirm.jsp:
Mais le problème n'est pas si simple. Le simple fait de faire cela n'est pas possible. Si vous faites cela, l'utilisateur clique en arrière et invitera à l'expiration de la page. Cependant, lorsque l'utilisateur le rafraîchit et ce n'est pas possible, le cache sera chargé avec les données d'origine. Nous comprenons donc une chose. Étant donné que la session n'a pas encore été close, il y a des informations de commande pour le Frander dans la session. Les utilisateurs continueront certainement d'obtenir ce français après l'avoir rafraîchi, et les informations de commande d'origine seront affichées. Par conséquent, le réglage dans la réception ne peut pas du tout résoudre le problème. Nous devons également effectuer un traitement pertinent en arrière-plan.
Étant donné que nous connaissons le problème, nous pouvons le faire: parce que lorsque l'utilisateur clique pour confirmer la commande, elle la remettra à FranderAction, puis après le traitement de l'alimentation de FranderAction, il passera à la page de paiement. Nous pouvons faire quelques astuces dans FranderAction: nous effacons le français d'origine dans la session, n'est-ce pas correct? Ceci est possible, mais étant donné que la commande est toujours pertinente pour la commande lors des paiements plus tard, nous pouvons enregistrer le français d'origine dans la session à un autre endroit, puis effacer le français d'origine. Nous ajoutons donc deux lignes de code à la fourraction ci-dessus, comme suit:
@Controller ("FORDERACTION") @Scope ("Prototype") Public Class ForderAction étend Baseaction <Ford> {@Override public Ford GetModel () {Model = (FORDER) Session.get ("FORDER"); modèle de retour; } // Implémentez la fonction de stockage en cascade du panier d'achat (commande) et des articles d'achat (articles de ligne) public public Save () {// // remettez les articles d'achat de la session à l'objet du modèle actuel // FORDER FORDER = (FORDER) Session.get ("FORDER"); // //model.setsorders (fourder.getSorders ()); //Forder.SetAddress (Model.getAddress ()); //Forder.SetName (Model.GetName ()); //Forder.SetPhone (Model.Getphone ()); //Forder.SetRemark (Model.getRemark ()); //Forder.SetUser((User)Session.get("User ")); //Forder.setStatus(New Status (1)); //Forder.SetPost (Model.GetPost ()); //Forder.SetPost (Model.GetPost ()); //Forder.SetUser((User)Session.get("User ")); //Forder.setStatus(New Status (1)); //Forder.SetPost (Model.GetPost ()); // // Storage en cascade (doit être configuré dans l'annotation de XML ou POJO), donc le Soorder est associé à FORDER // // Ajouter à la classe SorderserviceIMPL.save (fourder); //Forderservice.save(Forder); Model.SetUser ((utilisateur) session.get ("utilisateur")); Model.SetStatus (nouveau statut (1)); FORDERSERVICE.SAVE (modèle); // Le panier a été stocké dans le stockage, de sorte que le panier de la session d'origine doit être effacé Session.put ("OldForder", Session.get ("FORDER")); // Enregistrez les informations d'origine en premier, car les informations pertinentes sont requises lors du paiement de la session ultérieure. PUST ("FORDER", NEW FRAND ()); // NOUVEAU UN NOUVEAU CANTAGE INDICE ~ Banque à l'emploi pour le nettoyage de l'achat), qui peut également faciliter "une banque d'achat pour" }}Ensuite, avant de terminer, nous devons ajouter le code suivant pour confirmer la page de commande à la réception:
La logique est maintenant claire. Tout d'abord, lorsque la page de confirmation de commande, le fourder a des données, donc il n'est pas vide. Ce jugement n'est pas valide. Lorsque l'utilisateur clique pour confirmer la commande, dans FORDERACTION, nous remplaçons le Frander par un objet Fader vide, ce qui signifie que les données d'origine ont disparu (nous l'enregistrons dans une autre paire de valeurs clés dans la session pour un paiement ultérieur). De cette façon, lorsque l'utilisateur clique en arrière et revient à la page de confirmation de commande tout à l'heure, le jugement prend effet et passera à la page d'accueil. À ce stade, toute la logique est terminée et le problème du cache de la page est résolu.
Adresse originale: http://blog.csdn.net/eson_15/article/details/51433247
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.