Existem dois problemas restantes no carrinho de compras, a saber, o armazenamento em cascata das informações do pedido e do cache da página. As informações aqui se referem ao carrinho de compras e aos itens de compras. Ou seja, quando armazenamos as informações do carrinho de compras no banco de dados, também armazenamos as informações de cada item de compras e as chaves estrangeiras estão relacionadas, que envolve o problema de armazenamento em cascata no hibernado; O problema do cache da página refere -se ao momento em que o usuário confirmar o pedido, se ele clicar, ele retornará à página de confirmação do pedido. A página de confirmação do pedido agora sai novamente e a sessão ainda está lá, e as informações ainda são as informações agora. Obviamente, esse não é o resultado que queremos, e nós o analisamos um por um mais tarde. Esta seção discute principalmente os inventários em cascata das informações do pedido e o cache de páginas.
1. Armazenamento em cascata das informações do pedido
O armazenamento em cascata de duas tabelas relacionadas no hibernato precisa ser configurado. Aqui, apresentamos principalmente o método de configuração das anotações. O Pojo da Ordem é Forender, o Pojo do item de compras é mais sorvetendo, e o Forder e Sorder são relacionamentos de um para muitos. Primeiro, vamos definir a configuração da anotação, como segue:
@Entity public class FORDERMMEMMENTOS Java.io.Serializable {// omita código irrelevante ... Lista privada <sorder> Soorders = new ArrayList <sorder> (); @Onetomany (cascade = cascadetype.all, fetch = fetchtype.lazy, mapedby = "forder") list <sorder> getSorders () {return this.Sorders; } public void SetSorders (list <sorder> Soorders) {this.Sorders = Soorders; }} @Entity Public Class Sorder implementa java.io.Serializable {// omita código irrelevante ... Private Forder Forder; @ManytoOne (Fetch = fetchtype.lazy) @Joincolumn (name = "fid") public forder getforder () {return this.forder; } public void setForder (FORDER FORDER) {this.forder = forder; }} Após essa configuração, quando salvarmos itens de linha, também salvaremos os itens de compras e associaremos automaticamente as chaves estrangeiras. Mas a premissa é que precisamos definir a relação entre eles, ou seja, SetSorders () no FORDER, Setforder () no SoOrder e propriedades nas entidades correspondentes a outras chaves estrangeiras relacionadas.
Antes, quando adicionamos o item de compras ao carrinho de compras, FORDER.SetSord (Sorder) foi executado. Agora precisamos adicionar mais à parte, então adicionamos ao código original, como segue:
// Este é o código na Seção 17. Inserimos uma frase no Middle @service ("SorderService") Public Classe SorderServiceImpl estende o BaseServiceImpl <sorder> implementa SordserService {@Override public Forder AddSorder (FORDER FORDER, Product Product) {boolean isHave = Falseride; // usado para marcar se existem itens de compras duplicados // obtendo o item de compra atual Sorder SoOrder = ProductToSorde (Produto); // julga se o item de compra atual é duplicado. Se for duplicado, adicione a quantidade para (mais antigo: forder.getSorders ()) {if (Old.getProduct (). GetId (). Equals (Sorder.getProduct (). GetId ())) {// há duplicações para compras, adicione a quantidade antiga. ishave = true; quebrar; }} // O item de compra atual não existe no carrinho de compras, se (! Ishave) {// inserimos uma frase aqui: // Antes de adicionar o item de compras ao item de compras, primeiro estabelece a associação entre o item de compras e o carrinho de compras, mas nesse momento é que a empresa de compra e, ao mesmo tempo, entra no ware. Naquela época, existe a chave primária SoOrder.setForder (Foreder); forder.getSorders (). Add (Sorder); } retornar forder; } @Override Public Sorder ProductToDer (produto) {Sorder Soorder = new Sorder (); soorder.setName (product.getName ()); Soorder.SetNumber (1); soorder.setPrice (Product.getPrice ()); soorder.setProduct (Produto); Retornar Sorder; }}Ok, vamos dar uma olhada em qual ação para pular quando o pedido confirmar:
Então, vamos completar a lógica na FordAction:
@Controller ("FORDERACTION") @Scope ("prototype") classe pública forderaction estende o Baseaction <storder> {@Override public forder getModel () {model = (forder) session.get ("forder"); modelo de retorno; } // Implemente a função de armazenamento em cascata do carrinho de compras (ordem) e itens de compras (itens de linha) public string save () {// // entregue os itens de compras na sessão para o objeto de modelo atual // forder forder = (forder) session.get ("forder"); // //model.SetSorders (forder.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 ()); // // biblioteca em cascata (precisa ser configurada na anotação de XML ou POJO), para que a associação SoOrder Foreder seja necessária // // adicione à SordserServiceImpl class.setForder (FORDER); //ForderService.save(forder); model.setUser ((Usuário) session.get ("Usuário")); Model.SetStatus (novo status (1)); ForderService.Save (Modelo); retornar "banco"; }} Como pode ser visto no código acima, existem dois métodos: o primeiro não está substituindo o método getModel (a parte que eu comentei). Este método é bastante estúpido. Como a força herda a base e a base implementa a interface Model -Driven, os dados passados serão encapsulados no modelo. O modelo é uma propriedade em Baseation. Em seguida, precisamos passar todas as informações no modelo para o Forender na sessão e, em seguida, os dados no Forder podem estar em cascata com o Sorder para entrar na biblioteca. No entanto, esse método é um pouco estúpido ... por isso usamos o segundo método, reescrevemos o método getModel e atribuímos diretamente o Foreder ao modelo e, em seguida, precisamos adicionar os itens em cascata no modelo, ou seja, o código não anotado acima. Dessa forma, depois que o usuário clicar para confirmar o pedido, as informações serão inseridas no banco de dados e pulará para a página de pagamento (a página de pagamento precisa ser feita a seguir, para que você possa ir para um JSP primeiro).
2. Problemas de cache de páginas
Agora, a entrada em cascata das informações do pedido foi resolvida, mas se o usuário clicar para confirmar o pedido e depois voltar, descobrimos que ainda é a página de confirmação original do pedido, e as informações ainda são as informações agora e a sessão não está fechada, o que significa que tenho que confirmar as informações do pedido novamente, o que é obviamente inadequado. Em outras palavras, quando o usuário clica para confirmar o pedido, não podemos deixar o cache da página. Dessa forma, quando o usuário clicar para voltar, ele mostrará que a página expirou e apenas deixamos pular para a página inicial.
Sabemos que a página JSP front-end pode ser definida para que o navegador não cache os dados, para que possamos defini-los da seguinte forma na página do front-end Confirm.jsp:
Mas o problema não é tão simples. Apenas fazer isso não é possível. Se você fizer isso, o usuário clica e solicitará que a página expirou. No entanto, quando o usuário o atualiza e não é possível, o cache será carregado com os dados originais. Então, entendemos uma coisa. Como a sessão ainda não foi fechada, há uma informação de pedido para o Forender na sessão. Os usuários definitivamente continuarão a receber isso depois de atualizá -lo, e as informações originais do pedido serão exibidas. Portanto, definir isso na recepção não pode resolver o problema. Também precisamos fazer processamento relevante em segundo plano.
Como sabemos o problema, podemos fazer isso: porque quando o usuário clica para confirmar o pedido, ele o entregará à FordAction e, após a processamento da força, ele irá para a página de pagamento. Podemos fazer alguns truques na FordAction: limpamos o Forender original na sessão, não é ok? Isso é viável, mas, considerando que a ordem ainda é relevante para a ordem ao fazer pagamentos posteriormente, podemos salvar o Forender original na sessão em outro local e limpar o Forender original. Por isso, adicionamos duas linhas de código à força acima, como segue:
@Controller ("FORDERACTION") @Scope ("prototype") classe pública forderaction estende o Baseaction <storder> {@Override public forder getModel () {model = (forder) session.get ("forder"); modelo de retorno; } // Implemente a função de armazenamento em cascata do carrinho de compras (ordem) e itens de compras (itens de linha) public string save () {// // entregue os itens de compras na sessão para o objeto de modelo atual // forder forder = (forder) session.get ("forder"); // //model.SetSorders (forder.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 ()); // // armazenamento em cascata (precisa ser configurado na anotação de XML ou POJO), para que a Ordering esteja associada a FORDER // // adicione à SorderServiceImpl Class.Save (FORDER); //ForderService.save(forder); model.setUser ((Usuário) session.get ("Usuário")); Model.SetStatus (novo status (1)); ForderService.Save (Modelo); // O carrinho de compras foi armazenado no armazenamento; portanto, o carrinho de compras na sessão original deve ser limpo session.put ("OldForder", session.get ("FORDER")); // Salvar as informações originais do carrinho de compras primeiro, porque as informações relevantes são necessárias ao fazer o pagamento mais tarde ("FORDER", novo FORDER ()); // novo carrinho de compras vazio (equivalente a equivalente ("Forder", New Foreder ());); }}Em seguida, temos que adicionar o seguinte código à página de confirmação da recepção:
A lógica agora está clara. Primeiro, quando a página de confirmação do pedido, o Foreder possui dados, para que não esteja vazio. Este julgamento é inválido. Quando o usuário clica para confirmar o pedido, na FordAction, substituímos o Ford por um objeto Foreder vazio, o que significa que os dados originais desaparecem (nós o salvamos em outro par de valores-chave na sessão para pagamento posterior). Dessa forma, quando o usuário clica e retorna à página de confirmação do pedido agora, o julgamento entra em vigor e pulará para a página inicial. Neste ponto, toda a lógica está concluída e o problema do cache da página é resolvido.
Endereço original: http://blog.csdn.net/eson_15/article/details/51433247
O exposto acima é todo o conteúdo deste artigo. Espero que seja útil para o aprendizado de todos e espero que todos apoiem mais o wulin.com.