Hay dos problemas restantes en el carrito de compras, a saber, el almacenamiento en cascada de información de pedidos y caché de página. La información aquí se refiere al carrito de compras y artículos de compras. Es decir, cuando almacenamos la información del carrito de compras en la base de datos, también almacenamos la información de cada artículo de compra, y las claves extranjeras están relacionadas, lo que implica el problema de almacenamiento en cascada en Hibernate; El problema de la caché de la página se refiere al momento en que el usuario confirma el pedido, si hace clic, volverá a la página de confirmación del pedido. La página de confirmación del pedido recién vuelve a salir, y la sesión todavía está allí, y la información sigue siendo la información en este momento. Obviamente, este no es el resultado que queremos, y lo analizaremos uno por uno más tarde. Esta sección discute principalmente los inventarios en cascada de la información del pedido y el almacenamiento en caché de las páginas.
1. Almacenamiento en cascada de la información del pedido
Se debe configurar el almacenamiento en cascada de dos tablas relacionadas en Hibernate. Aquí presentamos principalmente el método de configuración de anotaciones. El pojo de la Orden es Forra, el pojo del artículo de compra es Sorder, y el Forra y Sorder son relaciones de uno a muchos. Primero, establezcamos su configuración de anotación, como sigue:
@Entity public class Forder implementa java.io.Serializable {// omitir código irrelevante ... Lista privada <Sorder> soorders = new ArrayList <Sorder> (); @Onetomany (cascade = cascadeType.all, fetch = fetchtype.lazy, mappedby = "fazder") Lista pública <Sorder> getSorders () {return this.sorders; } public void setSorders (List <Sorder> soorders) {this.sorders = soorders; }} @Entity Public Class Sorder implementa java.io.serializable {// omitir código irrelevante ... Forra privada Forra; @ManyToOne (fetch = fetchType.lazy) @Joincolumn (name = "fid") public Forder getForder () {return this.forder; } public void setforder (Forder Forder) {this.forder = Forder; }} Después de esta configuración, cuando guardamos elementos de línea, también guardaremos los artículos de compras y asociaremos automáticamente las claves extranjeras. Pero la premisa es que necesitamos establecer la relación entre ellos, es decir, setsorders () en la orilla, setforder () en el soord y propiedades en las entidades correspondientes a otras claves extranjeras relacionadas.
Antes, cuando agregamos el artículo de compra al carrito de compras, se ejecutó Forder.SetsOrder (Sorder). Ahora necesitamos agregar Forra al Soorder, por lo que la agregamos al código original, como sigue:
// Este es el código en la sección 17. Insertamos una oración en el medio @service ("sorderservice") clase pública sorderserviceImpl extiende BasesServiceImpl <Sorder> implementa sorderservice {@Override public addsorder (Forder Forder, producto de producto) {boolean ishave = falso; // se usa para marcar si hay artículos de compras duplicados // Obtener el artículo de compra actual Sorder Soorder = ProductToSorder (producto); // juzga si el artículo de compra actual está duplicado. Si está duplicado, agregue la cantidad para (Sorder Old: Forder.getSorders ()) {if (Old.getProduct (). GetId (). Equals (Sorder.getProduct (). GetId ()) {// Hay duplicados para elementos de compra, agregue la cantidad Old.SetNumber (Old.getNumber () + soorder.getNumber ()); ishave = verdadero; romper; }} // El artículo de compra actual no existe en el carrito de compras, if (! Ishave) {// Insertamos una oración aquí: // Antes de agregar el artículo de compra al artículo de compra, establece la asociación entre el artículo comercial y el carrito de compras, pero en este momento la caos es nulo, // pero al ingresar al Warehouse, primero ingresa al carrito de compras de Warehouse y luego ingresa al artículo de compras Warehouse. En ese momento, existe la clave principal SOORDER.SETFORD (Forder); Forder.getSorders (). Agregar (Sorder); } return fazer; } @Override public Sorder ProductToSorder (producto Producto) {Sorder soorder = new Sorder (); soorder.setName (producto.getName ()); soorder.setNumber (1); soorder.setPrice (producto.getPrice ()); soorder.setProduct (producto); Sorder de regreso; }}Ok, echemos un vistazo a qué acción saltar cuando el pedido confirme:
Así que vamos a completar la lógica en la orilla de la orilla:
@Controller ("ForderAction") @Scope ("Prototype") Public Class ForderAction extiende BASEACTION <foster> {@Override public Forder GetModel () {Model = (Forder) Session.get ("Fosder"); modelo de retorno; } // Implementar la función de almacenamiento en cascada del carrito de compras (pedido) y artículos de compras (elementos de pedido) String public save () {// // entrega los artículos de compras en la sesión al objeto de modelo actual // Forder Forder = (Forder) Session.get ("Fosder"); // //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 en cascada (debe configurarse en la anotación de XML o POJO), por lo que se requiere la orilla de la asociación SOORDER // // Agregar a la clase SorderserviceImpl. //Forderservice.save(forder); model.setUser ((usuario) session.get ("usuario")); Model.SetStatus (nuevo estado (1)); ForderService.save (modelo); devolución de "banco"; }} Como se puede ver en el código anterior, hay dos métodos: el primero no está anulando el método GetModel (la parte que comenté). Este método es bastante estúpido. Dado que ForderAction hereda la reacción de la base, y Baseaction implementa la interfaz ModelDiven, los datos pasados se encapsularán en el modelo. El modelo es una propiedad en Baseaction. Luego necesitamos pasar toda la información en el modelo al fazador en la sesión, y luego los datos en el fazador pueden estar en cascada con Sorder para ingresar a la biblioteca. Sin embargo, este método es un poco estúpido ... por lo que usamos el segundo método, reescribimos el método GetModel y asignamos directamente el Facera al modelo, y luego solo necesitamos agregar los elementos en cascada en el modelo, es decir, el código no anotado anterior. De esta manera, después de que el usuario hace clic para confirmar el pedido, la información se ingresará en la base de datos y saltará a la página de pago (la página de pago debe hacerse a continuación, para que pueda saltar a un JSP primero).
2. Problemas de almacenamiento en caché de la página
Ahora se ha resuelto la entrada en cascada de la información del pedido, pero si el usuario hace clic para confirmar el pedido y luego de regreso, encontramos que sigue siendo la página de confirmación del pedido original, y la información sigue siendo la información en este momento, y la sesión no está cerrada, lo que significa que tengo que confirmar la información del pedido nuevamente, lo que obviamente es inapropiado. En otras palabras, cuando el usuario hace clic para confirmar el pedido, no podemos dejar que el almacenamiento en caché de la página. De esta manera, cuando el usuario hace clic para respaldar, mostrará que la página ha expirado, y simplemente lo dejamos saltar a la página de inicio.
Sabemos que la página JSP front-end se puede configurar para que el navegador no almacene en caché los datos, por lo que podamos configurarlo de la siguiente manera en la página Confirm.jsp: JSP:
Pero el problema no es tan simple. Solo hacer esto no es posible. Si hace esto, el usuario hace clic y solicitará que la página haya expirado. Sin embargo, cuando el usuario lo actualiza y no es posible, el caché se cargará con los datos originales. Entonces entendemos una cosa. Dado que la sesión aún no se ha cerrado, hay una información de pedido para el fazador en la sesión. Los usuarios definitivamente continuarán obteniendo esta cartera después de actualizarla, y se mostrará la información del pedido original. Por lo tanto, configurar esto en la recepción no puede resolver el problema en absoluto. También necesitamos hacer un procesamiento relevante en segundo plano.
Como sabemos el problema, podemos hacer esto: porque cuando el usuario hace clic para confirmar el pedido, lo entregará a ForderAction, y luego, después de procesarse la ForderAction, saltará a la página de pago. Podemos hacer algunos trucos en Forderaction: aclaramos la cartera original en la sesión, ¿no está bien? Esto es factible, pero teniendo en cuenta que el pedido sigue siendo relevante para el pedido al hacer pagos más tarde, podemos ahorrar el vaso original en la sesión a otro lugar y luego despejar el vaso original. Entonces agregamos dos líneas de código a la ForderAction anterior, como sigue:
@Controller ("ForderAction") @Scope ("Prototype") Public Class ForderAction extiende BASEACTION <foster> {@Override public Forder GetModel () {Model = (Forder) Session.get ("Fosder"); modelo de retorno; } // Implementar la función de almacenamiento en cascada del carrito de compras (pedido) y artículos de compras (elementos de pedido) String public save () {// // entrega los artículos de compras en la sesión al objeto de modelo actual // Forder Forder = (Forder) Session.get ("Fosder"); // //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 ()); // // Almacenamiento en cascada (es necesario configurar en la anotación de XML o POJO), por lo que el SOORDER está asociado con Forder // // Agregar a SorderserviceImpl class.save (Forder); //Forderservice.save(forder); model.setUser ((usuario) session.get ("usuario")); Model.SetStatus (nuevo estado (1)); ForderService.save (modelo); // El carrito de compras se ha almacenado en el almacenamiento, por lo que el carrito de compras en la sesión original debe borrarse session.put ("OldForder", Session.get ("Forder"))); // Guarde la información de compras original primero, porque se requiere información relevante al realizar el pago posterior. }}Luego, antes de terminar, tenemos que agregar el siguiente código para confirmar la página de pedido en la recepción:
La lógica ahora está clara. Primero, cuando la página de confirmación del pedido, el fazador tiene datos, por lo que no está vacío. Este juicio no es válido. Cuando el usuario hace clic para confirmar el pedido, en ForderAction reemplazamos la cartera con un objeto de vaso vacío, lo que significa que los datos originales han desaparecido (lo guardamos en otro par de valores clave en la sesión para el pago posterior). De esta manera, cuando el usuario hace clic y regresa a la página de confirmación de pedidos en el momento, el juicio entra en vigencia y saltará a la página de inicio. En este punto, toda la lógica está completa y el problema de la caché de la página se resuelve.
Dirección original: http://blog.csdn.net/eson_15/article/details/514333247
Lo anterior es todo el contenido de este artículo. Espero que sea útil para el aprendizaje de todos y espero que todos apoyen más a Wulin.com.