Ada dua masalah yang tersisa di keranjang belanja, yaitu penyimpanan informasi pesanan dan cache halaman. Informasi di sini mengacu pada keranjang belanja dan barang -barang belanja. Artinya, ketika kami menyimpan informasi keranjang belanja ke dalam database, kami juga menyimpan informasi dari setiap item belanja, dan kunci asing terkait, yang melibatkan masalah penyimpanan yang dikurung di hibernate; Masalah cache halaman mengacu pada waktu ketika pengguna mengkonfirmasi pesanan, jika dia mengklik kembali, dia akan kembali ke halaman konfirmasi pesanan. Halaman konfirmasi pesanan baru saja keluar lagi, dan sesi masih ada, dan informasinya masih informasi sekarang. Ini jelas bukan hasil yang kami inginkan, dan kami akan menganalisisnya satu per satu nanti. Bagian ini terutama membahas inventaris informasi pesanan dan caching halaman.
1. Cascading Penyimpanan Informasi Pesanan
Penyimpanan cascading dari dua tabel terkait di Hibernate perlu dikonfigurasi. Di sini kami terutama memperkenalkan metode konfigurasi anotasi. Pojo dari pesanan adalah Forder, pojo dari item belanja adalah SURDER, dan FORDER DAN PERUKU adalah hubungan satu-ke-banyak. Pertama, mari atur konfigurasi anotasi mereka, sebagai berikut:
@Entity Public Class FORDER mengimplementasikan java.io.serializable {// hilangkan kode yang tidak relevan ... Daftar pribadi <Sherder> Soorders = new ArrayList <Sherder> (); @Onetomany (cascade = cascadetype.all, fetch = fetchType.lazy, mappedby = "forder") Daftar publik <sherder> gotorders () {return this.sorders; } public void setSorders (Daftar <Sherder> Soorders) {this.sorders = Soorders; }} @Entity Public Class Sherder mengimplementasikan java.io.serializable {// menghilangkan kode yang tidak relevan ... Private FORDER FORDER; @ManytoOne (fetch = fetchType.lazy) @joincolumn (name = "fid") public forder getForder () {return this.forder; } public void setForder (FORDER FORDER) {this.FORDER = FORDER; }} Setelah konfigurasi ini, ketika kami menyimpan item baris, kami juga akan menyimpan item belanja dan secara otomatis mengaitkan kunci asing. Tetapi premisnya adalah bahwa kita perlu mengatur hubungan di antara mereka, yaitu, setSorders () di Forder, SetForder () di Soorder, dan Properti di entitas yang sesuai dengan kunci asing terkait lainnya.
Sebelumnya, ketika kami menambahkan item belanja ke keranjang belanja, Forder.setsorder (SERODER) dieksekusi. Sekarang kita perlu menambahkan Forder ke Soorder, jadi kita menambahkannya ke kode asli, sebagai berikut:
// Ini adalah kode di bagian 17. Kami memasukkan kalimat di tengah @Service ("SorderService") kelas publik SorderServiceImpl memperluas baseServiceImpl <sherder> mengimplementasikan sorderService {@Override public forder addSorder (forder forder, produk produk) {boolean ishave = false; // Digunakan untuk menandai apakah ada duplikat item belanja // dapatkan item belanja saat ini SORDER SOORDER = ProductToSorder (Produk); // menilai apakah item belanja saat ini digandakan. Jika digandakan, tambahkan kuantitas untuk (SORDER lama: forder.getSorders ()) {if (old.getProduct (). GetId (). Equals (SoRDER.GetProduct (). GetId ()) {// Ada duplikat untuk item belanja, tambahkan kuantitas lama.setnumber (get.get.get.get.) ishave = true; merusak; }} // Item belanja saat ini tidak ada di keranjang belanja, jika (! IsHave) {// kami memasukkan kalimat di sini: // sebelum menambahkan item belanja ke item belanja, pertama -tama buat hubungan antara item belanja dan keranjang belanja, tetapi saat ini Forder. Pada saat itu, ada kunci utama Soorder.setForder (FORDER); FORDER.GETSORDERS (). Tambah (SURDER); } return fonder; } @Override Public Sehol ProductToSorder (Produk Produk) {SORDER SOORDER = NEW SERODER (); soorder.setname (product.getName ()); Soorder.setNumber (1); soorder.setPrice (product.getPrice ()); soorder.setProduct (produk); Kembalikan Persahai; }}Oke, mari kita lihat tindakan mana yang harus dilompat ke saat pesanan mengkonfirmasi:
Jadi kami pergi untuk menyelesaikan logika di Forderaction:
@Controller ("FORDERACTION") @Scope ("ProtoType") Kelas Publik ForderAction memperluas basa <BREDER> {@Override public forder getModel () {model = (forder) session.get ("forder"); model pengembalian; } // Menerapkan fungsi penyimpanan cascaded dari keranjang belanja (pesanan) dan item belanja (item baris) string publik save () {// // menyerahkan item belanja di sesi ke objek model saat ini // 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("Aser ")); //forder.setstatus( status baru (1)); //forder.setPost (model.getPost ()); //forder.setPost (model.getPost ()); //forder.setuser((user)Session.get("Aser ")); //forder.setstatus( status baru (1)); //forder.setPost (model.getPost ()); // // Perpustakaan Cascaded (perlu dikonfigurasi dalam anotasi XML atau POJO), sehingga Soorder Association Forder diperlukan // // Tambahkan ke SorderServiceImpl class.setForder (FORDER); //Forderservice.save(Forder); model.setUser ((user) session.get ("user")); model.setstatus (status baru (1)); FORDERSERVICE.SAVE (model); mengembalikan "bank"; }} Seperti yang dapat dilihat dari kode di atas, ada dua metode: yang pertama tidak mengesampingkan metode getModel (bagian yang saya komentari). Metode ini cukup bodoh. Karena Forderaction mewarisi basa, dan basa mengimplementasikan antarmuka yang dimodelkan, data yang disahkan akan dienkapsulasi ke dalam model. Model adalah properti di basa. Maka kita perlu meneruskan semua informasi dalam model ke Forder di sesi, dan kemudian data di Forder dapat mengalir dengan Subder untuk memasuki perpustakaan. Namun, metode ini agak bodoh ... jadi kami menggunakan metode kedua, menulis ulang metode GetModel, dan langsung menetapkan forder ke model, dan kemudian kami hanya perlu menambahkan item cascading dalam model, yaitu, kode yang tidak dianotasi di atas. Dengan cara ini, setelah pengguna mengklik untuk mengonfirmasi pesanan, informasi akan dimasukkan ke dalam database dan melompat ke halaman pembayaran (halaman pembayaran perlu dilakukan berikutnya, sehingga Anda bisa melompat ke JSP terlebih dahulu).
2. Masalah caching halaman
Sekarang entri cascading dari informasi pesanan telah diselesaikan, tetapi jika pengguna mengklik untuk mengonfirmasi pesanan dan kemudian kembali, kami menemukan bahwa itu masih halaman konfirmasi pesanan asli, dan informasi masih informasi sekarang, dan sesi tersebut tidak ditutup, yang berarti bahwa saya harus mengkonfirmasi informasi pesanan lagi, yang jelas tidak pantas. Dengan kata lain, ketika pengguna mengklik untuk mengonfirmasi pesanan, kami tidak dapat membiarkan halaman cache. Dengan cara ini, ketika pengguna mengklik untuk mendukung, itu akan menunjukkan bahwa halaman telah kedaluwarsa, dan kami membiarkannya melompat ke beranda.
Kita tahu bahwa halaman JSP front-end dapat diatur sehingga browser tidak menembus data, sehingga kami dapat mengaturnya sebagai berikut di halaman front-end konfirmasi.jsp:
Tapi masalahnya tidak sesederhana itu. Hanya melakukan ini tidak mungkin. Jika Anda melakukan ini, pengguna mengklik kembali dan akan meminta halaman telah kedaluwarsa. Namun, ketika pengguna menyegarkannya dan tidak mungkin, cache akan dimuat dengan data asli. Jadi kami memahami satu hal. Karena sesi belum ditutup, ada informasi pesanan untuk Forder di sesi. Pengguna pasti akan terus mendapatkan Funder ini setelah menyegarkannya, dan informasi pesanan asli akan ditampilkan. Oleh karena itu, mengatur ini di meja depan tidak dapat menyelesaikan masalah sama sekali. Kami juga perlu melakukan pemrosesan yang relevan di latar belakang.
Karena kita tahu masalahnya, kita dapat melakukan ini: karena ketika pengguna mengklik untuk mengonfirmasi pesanan, itu akan menyerahkannya ke Forderaction, dan kemudian setelah Forderaction diproses, itu akan melompat ke halaman pembayaran. Kita dapat melakukan beberapa trik di Forderaction: Kami membersihkan Forder asli di sesi, bukankah tidak apa -apa? Ini layak, tetapi mengingat bahwa pesanan masih relevan dengan pesanan ketika melakukan pembayaran nanti, kita dapat menyimpan Funder asli di sesi ke tempat lain dan kemudian membersihkan Funder asli. Jadi kami menambahkan dua baris kode ke Forderaction di atas, sebagai berikut:
@Controller ("FORDERACTION") @Scope ("ProtoType") Kelas Publik ForderAction memperluas basa <BREDER> {@Override public forder getModel () {model = (forder) session.get ("forder"); model pengembalian; } // Menerapkan fungsi penyimpanan cascaded dari keranjang belanja (pesanan) dan item belanja (item baris) string publik save () {// // menyerahkan item belanja di sesi ke objek model saat ini // 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("Aser ")); //forder.setstatus( status baru (1)); //forder.setPost (model.getPost ()); //forder.setPost (model.getPost ()); //forder.setuser((user)Session.get("Aser ")); //forder.setstatus( status baru (1)); //forder.setPost (model.getPost ()); // // penyimpanan bertingkat (perlu dikonfigurasi dalam anotasi XML atau POJO), sehingga Soorder dikaitkan dengan FORDER // // Tambahkan ke SorderServiceImpl class.save (FORDER); //Forderservice.save(Forder); model.setUser ((user) session.get ("user")); model.setstatus (status baru (1)); FORDERSERVICE.SAVE (model); //The shopping cart has been stored in the storage, so the shopping cart in the original session should be cleared session.put("oldForder", session.get("forder"));//Save the original shopping cart information first, because relevant information is required when making payment later session.put("forder", new Forder());//New A new empty shopping cart (equivalent to clearing the shopping cart), which can also facilitate users to buy again~ return "bank"; }}Kemudian, sebelum kita selesai, kita harus menambahkan kode berikut untuk mengonfirmasi halaman pesanan di meja depan:
Logikanya sekarang jelas. Pertama, ketika halaman konfirmasi pesanan, Forder memiliki data, sehingga tidak kosong. Penghakiman ini tidak valid. Ketika pengguna mengklik untuk mengonfirmasi pesanan, di Forderaction kami mengganti Forder dengan objek Forder kosong, yang berarti bahwa data asli hilang (kami menyimpannya dalam pasangan nilai kunci lain di sesi untuk pembayaran selanjutnya). Dengan cara ini, ketika pengguna mengklik kembali dan kembali ke halaman konfirmasi pesanan sekarang, penilaian mulai berlaku dan akan melompat ke beranda. Pada titik ini, seluruh logika selesai dan masalah cache halaman terpecahkan.
Alamat asli: http://blog.csdn.net/eson_15/article/details/51433247
Di atas adalah semua konten artikel ini. Saya berharap ini akan membantu untuk pembelajaran semua orang dan saya harap semua orang akan lebih mendukung wulin.com.