В корзине есть две оставшиеся проблемы, а именно каскадное хранение информации о заказе и кеша страниц. Информация здесь относится к корзину и предметам покупок. То есть, когда мы храним информацию о корзине для покупок в базе данных, мы также храним информацию каждого предмета покупки, и иностранные ключи связаны, что включает в себя каскадированную проблему хранения в Hibernate; Проблема кэша страниц относится к времени, когда пользователь подтверждает заказ, если он нажимает назад, он вернется на страницу подтверждения заказа. Страница подтверждения заказа только сейчас выходит снова, и сеанс все еще существует, и информация все еще остается информацией только сейчас. Это, очевидно, не тот результат, который мы хотим, и мы проанализируем его один за другим. В этом разделе в основном обсуждаются каскадные запасы информации о заказе и кэширование страниц.
1. Каскадный хранение информации о заказе
Необходимо настроить каскадную хранение двух связанных таблиц в Hibernate. Здесь мы в основном представляем метод конфигурации аннотаций. Похово из ордена-Forder, Pojo предмет покупок-это сложное, а Forder и Sorder-это отношения от одного ко многим. Во -первых, давайте установим конфигурацию их аннотации следующим образом:
@Entity Public Class Forder реализует java.io.serializable {// опустить нерелевантный код ... частный список <sorder> soorders = new Arraylist <sorder> (); @Onetomany (cascade = cascadetype.all, fetch = fetchtype.lazy, mapedby = "forder") public list <sorder> getsorders () {return this.sorders; } public void setSorders (List <Sorder> soorders) {this.sorders = soorders; }} @Entity Public Class Sorder реализует java.io.serializable {// опустить нерелевантный код ... Частный Forder Forder; @Manytoone (fetch = fetchtype.lazy) @joincolumn (name = "fid") public forder getForder () {return this.forder; } public void setForder (forder forder) {this.forder = forder; }} После этой конфигурации, когда мы сохраняем позиции линии, мы также сохраним предметы покупок и автоматически связываем иностранные ключи. Но предпосылка заключается в том, что нам нужно установить отношения между ними, то есть setSorders () в Forder, SetForder () в SOORDER, и свойства в объектах, соответствующих другим связанным иностранным ключам.
Раньше, когда мы добавили товар для покупки в корзину, Forder.setsorder (Sorder) был выполнен. Теперь нам нужно добавить Forder в SOORDE, поэтому мы добавляем его в исходный код, следующим образом:
// Это код в разделе 17. Мы вставляем предложение в середину @Service («Sorderservice») Общедоступный класс SorderServiceImpl Extens BaseserviceImpl <sorder> реализует Sorderservice {@Override Public Forder AddsOrdsord (Forder Forder, продукт продукт) {Boolean Ishave = false; // используется, чтобы отметить, есть ли дублируемые предметы для покупок // Получить текущие товары для покупок Sorder SOORD = ProductToSord (Product); // Судите, дублируется ли текущий предмет покупок. Если он дублируется, добавьте количество для (sorder old: forder.getsorders ()) {if (old.getProduct (). GetId (). Equals (sorder.getProduct (). GetId ())) {// Существуют дубликаты для предметов для покупок, добавьте количество Old.setNumber (old.getnumber () + soorder. ishave = true; перерыв; }} // Текущий предмет покупок не существует в корзине, если (! Ishave) {// Мы вставляем здесь предложение: // Перед тем, как добавить предмет покупок в предмет покупок, сначала установите ассоциацию между предметом для покупок и корзиной для покупок, но в это время Forder.id - это NULL, //, но при входе в склад, вы сначала входите в корзину для магазина Warehous В то время есть первичный ключ Soorder.setForder (Forder); forder.getSorders (). Add (Sorder); } вернуть Forder; } @Override public sorder producttosorder (продукт продукт) {sorder soorder = new Sorder (); soorder.setname (product.getName ()); soorder.setnumber (1); SOORDE.SetPrice (product.getPrice ()); soorder.setProduct (продукт); вернуть сордер; }}Хорошо, давайте посмотрим, к какому действию, чтобы прыгнуть, когда заказ подтверждает:
Итак, мы идем, чтобы завершить логику в Forderaction:
@Controller ("forderaction") @scope ("прототип") открытый класс Forderaction расширяет базовый <forder> {@override public forder getmodel () {model = (forder) session.get ("forder"); вернуть модель; } // Реализовать функцию каскадного хранения корзины для покупок (заказ) и предметов покупки (строки) public String save () {// // передавать предметы покупки в сеансе текущему объекту модели // 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 ()); // // Каскадированная библиотека (должна быть настроена в аннотации XML или POJO), поэтому требуется фордер ассоциации SOORDER // // Добавить в SorderServiceImpl Class.SetForder (Forder); //Forderservice.save(forder); model.setuser ((пользователь) session.get ("user")); model.setStatus (новый статус (1)); forderservice.save (модель); вернуть "банк"; }} Как видно из приведенного выше кода, есть два метода: первый не переопределяет метод GetModel (часть, которую я прокомментировал). Этот метод довольно глуп. Поскольку FORDERACTION наследует базоазакнув, а базойкция реагирует интерфейс модели, передаваемые данные будут инкапсулированы в модель. Модель - это свойство в базеатровании. Затем нам нужно передать всю информацию в модели в Forder в сеансе, а затем данные в Forder могут каскадировать со Сордером для входа в библиотеку. Тем не менее, этот метод немного глуп ... поэтому мы используем второй метод, переписываем метод GetModel и напрямую присваивайте Forder модели, а затем нам просто нужно добавить каскадные элементы в модель, то есть не аннотированный код выше. Таким образом, после того, как пользователь нажимает, чтобы подтвердить заказ, информация будет введена в базу данных и перейти на страницу оплаты (страница оплаты должна быть сделана дальше, так что вы можете просто перейти к JSP).
2. Проблемы с кэшированием страницы
Теперь каскадная запись информации о заказе была решена, но если пользователь нажимает, чтобы подтвердить заказ, а затем вернуться, мы обнаруживаем, что это все еще исходная страница подтверждения заказа, а информация все еще остается информацией только сейчас, и сеанс не закрыт, что означает, что я должен снова подтвердить информацию о заказе, что, очевидно, является неуместной. Другими словами, когда пользователь нажимает, чтобы подтвердить заказ, мы не можем позволить кэше страницы. Таким образом, когда пользователь нажимает, чтобы вернуться, он покажет, что страница истек, и мы просто позволили ей прыгнуть на домашнюю страницу.
Мы знаем, что передняя страница JSP может быть установлена так, чтобы браузер не кэшировал данные, чтобы мы могли установить ее следующим образом на переднем конце.
Но проблема не такая проста. Просто сделать это невозможно. Если вы сделаете это, пользователь нажимает назад и подскажет, что страница истек. Однако, когда пользователь обновляет его, и это невозможно, кэш будет загружен исходными данными. Итак, мы понимаем одну вещь. Поскольку сессия еще не была закрыта, в сеансе есть информация о заказе. Пользователи определенно будут продолжать получать этот Forder после обновления его, и будет отображаться исходная информация о заказе. Следовательно, установление этого в стойке регистрации не может вообще решить проблему. Нам также необходимо выполнить соответствующую обработку в фоновом режиме.
Поскольку мы знаем проблему, мы можем сделать это: потому что, когда пользователь нажимает, чтобы подтвердить заказ, он передаст его на Forderaction, а затем после обработки Forderaction, он перейдет на страницу оплаты. Мы можем сделать несколько трюков в Forderaction: мы очищаем оригинальный Forder на сессии, разве это не нормально? Это возможно, но, учитывая, что заказ по -прежнему имеет отношение к заказу при выплате платежей позже, мы можем сохранить оригинальный Forder в сеансе в другом месте и очистить первоначальный Forder. Таким образом, мы добавляем две строки кода в вышеупомянутую Forderaction, следующим образом:
@Controller ("forderaction") @scope ("прототип") открытый класс Forderaction расширяет базовый <forder> {@override public forder getmodel () {model = (forder) session.get ("forder"); вернуть модель; } // Реализовать функцию каскадного хранения корзины для покупок (заказ) и предметов покупки (строки) public String save () {// // передавать предметы покупки в сеансе текущему объекту модели // 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 ()); // // каскадное хранилище (необходимо настроить в аннотации XML или POJO), поэтому SOORD связан с FORDER // // Добавить в SorderServiceImpl class.save (Forder); //Forderservice.save(forder); model.setuser ((пользователь) session.get ("user")); model.setStatus (новый статус (1)); forderservice.save (модель); // В хранилище хранится корзина для покупок, поэтому корзина для покупок в оригинальной сессии должна быть очищена Session.put («OldForder», Session.get («Forder»)); // Сначала сохранение оригинальной информации корзины для покупок, потому что соответствующая информация требуется при выплате более поздней сессии. Получение («Forder», New Forder ()); // новая новая пустая корзина для покупок («Forder», что может также можно вернуть, что может также можно вернуть, что может также можно вернуть, что может также можно вернуть, что может также можно вернуть, что может также можно вернуть, что может также можно найти новую корзину для покупок («Forder»), которые могут также выкупаться, которые также могут быть выкуплены, которые также могут быть выкупают. }}Затем мы должны добавить следующий код на страницу подтверждения стойки регистрации:
Логика теперь ясна. Во -первых, когда страница подтверждения заказа у Forder есть данные, поэтому он не пуст. Это суждение недействительно. Когда пользователь нажимает, чтобы подтвердить заказ, в Forderaction мы заменяем Forder пустым объектом Forder, что означает, что исходные данные исчезли (мы сохраняем его в другой паре ключевых значений в сеансе для последующего оплаты). Таким образом, когда пользователь нажимает назад и возвращается на страницу подтверждения заказа, решение вступит в силу и перейдет на домашнюю страницу. На этом этапе вся логика завершена, и проблема кэша страниц решается.
Оригинальный адрес: http://blog.csdn.net/eson_15/article/details/51433247
Выше всего содержание этой статьи. Я надеюсь, что это будет полезно для каждого обучения, и я надеюсь, что все будут поддерживать Wulin.com больше.