ASP.NET MVC - TempData - Praktik yang baik atau buruk

96

Saya menggunakan AcceptVerbsmetode yang dirinci dalam posting blog Scott Gu's Preview 5 untuk menangani entri formulir di ASP.NET MVC:

  • Pengguna mendapatkan formulir kosong melalui GET
  • Pengguna memposting formulir yang telah diisi melalui POST ke Tindakan yang sama
  • Tindakan memvalidasi data, mengambil tindakan yang sesuai, dan mengalihkan ke tampilan baru

Jadi saya tidak harus menggunakan TempData. Karena itu, saya sekarang harus menambahkan langkah 'konfirmasi' ke proses ini, dan tampaknya memerlukan penggunaan TempData.

Untuk beberapa alasan, saya enggan menggunakan TempData- bahwa itu adalah sesuatu yang dirancang khusus.

Apakah ini masalah yang benar, atau saya mengada-ada?

asp.net-mvc  tempdata 
— anonim
sumber
1
Pertimbangkan untuk menjadikan langkah 'konfirmasi' Anda sebagai dialog javascript. Lebih sedikit perjalanan pulang pergi server dan Anda tidak akan mengalami masalah ini.
— ajma

Jawaban:

26

Saya menganggap data temp sebagai mekanisme api-dan-lupakan untuk memberi tahu pengguna. Sangat menyenangkan memberi mereka pengingat tentang sesuatu yang baru-baru ini mereka lakukan, tetapi saya juga ragu untuk menjadikannya langkah yang diperlukan dalam beberapa proses pengguna. Alasannya adalah jika mereka menyegarkan halaman, saya yakin halaman itu akan hilang. Saya rasa saya juga ragu untuk menggunakannya karena tidak begitu jelas seberapa dapat diandalkannya.

Saya ingin tahu apakah masalahnya adalah Anda memiliki tindakan yang dialihkan ke halaman lain sebelum langkah konfirmasi. Saya ingin tahu apakah setelah mereka mengirim pertama kali, Anda dapat melakukan cukup pemrosesan untuk menghasilkan dialog konfirmasi, lalu mengembalikan halaman asli dengan pertanyaan konfirmasi. Mirip dengan cara Anda melakukan validasi, kecuali aturan validasi memeriksa apakah langkah konfirmasi telah dilakukan (dengan UI konfirmasi disembunyikan hingga validasi lain lolos).

— Frank Schwieterman
sumber
77

Tidak perlu enggan menggunakan TempData ... Tapi jika tidak digunakan dengan benar pasti bisa menjadi indikasi desain yang buruk. Jika Anda menggunakan RESTful URL's, TempData adalah praktik terbaik untuk mentransfer pesan dari Tindakan POST Anda ke Tindakan GET Anda. Pertimbangkan ini:

Anda memiliki formulir di URL Products / New. Formulir Posting ke Produk / Buat, yang memvalidasi formulir dan membuat Produk, Jika Berhasil, Pengontrol mengalihkan ke URL Produk / 1 dan saat terjadi kesalahan akan mengarahkan kembali ke produk / Baru untuk menampilkan Pesan Kesalahan.

Products / 1 hanyalah tindakan GET standar untuk produk, tetapi kami ingin pesan ditampilkan yang menunjukkan bahwa penyisipan berhasil. TempData sempurna untuk ini. Tambahkan pesan ke TempData di Post Controller dan masukkan logika if dalam tampilan dan selesai.

Jika gagal, saya telah menambahkan nilai yang dimasukkan di formCollection dan kumpulan Pesan kesalahan ke TempData di Tindakan Posting, dan mengalihkan ke Tindakan Prodcuts awal / Baru. Saya telah menambahkan logika ke tampilan untuk mengisi input formulir dengan nilai yang dimasukkan sebelumnya bersama dengan pesan kesalahan apa pun. Tampak bagus dan bersih bagiku!

— JasonD
sumber
1
Mengapa pekerjaan ekstra itu ketika Anda dapat memposting langsung kembali Products/New? Nilai apa yang Products/Createditambahkan?
— mpen
2
@Mark, menggunakan Products / Create mencegah situasi di mana pengguna menyelesaikan tindakan melalui postback, lalu di refresh nanti (atau bookmark & ​​return) secara tidak sengaja menyelesaikan kembali tindakan tersebut. Untuk lebih lanjut, lihat en.wikipedia.org/wiki/Post/Redirect/Get
— ehdv
3
@ehdv: Tapi benarkah? Jika berhasil, ia mengalihkan ke halaman lain, jika gagal, formulir tersebut akan menampilkan kesalahan dan tidak ada tindakan yang harus diambil, jadi tidak ada kerusakan yang terjadi. Ini hanya akan mencegah pesan "apakah Anda yakin ingin memposting ulang" yang mengganggu, yang sering saya inginkan. Saya kira itu tergantung pada desain Anda, jadi saya bisa mengerti maksud Anda.
— mpen
31

Saya pikir Anda sebaiknya ragu sebelum menggunakan TempData. TempData disimpan dalam sesi dan ini mungkin berdampak bagi Anda jika:

  1. Anda tidak menggunakan sesi di situs Anda sekarang
  2. Anda memiliki sistem yang perlu diskalakan ke throughput tinggi, misalnya Anda lebih suka menghindari status sesi sama sekali
  3. Anda tidak ingin menggunakan cookie (saya tidak tahu seberapa baik MVC mendukung sesi tanpa cookie sekarang)

Jika situs Anda perlu memiliki ketersediaan tinggi, maka ada pertimbangan tambahan seputar penerapan status sesi tetapi ini semua adalah masalah yang dapat dipecahkan.

— John Rayner
sumber
16
TempData tidak harus disimpan dalam sesi, meskipun itu adalah penyedia default - yang mungkin mengapa tidak ada dalam metode doc. Ada juga penyedia cookie di luar sana, sebagai contoh cara menulis penyedia kustom.
— FinnNk
3

Saya memiliki metode GetModel yang pertama kali memeriksa TempData ["model"] dan mengembalikannya. Jika tidak, GetModel memuat data yang sesuai dari database.

Ini menghemat beban ekstra dari database ketika saya memiliki tindakan yang perlu mengembalikan tampilan berbeda yang memerlukan data model yang sama.

— Todd Smith
sumber
Yah, saya telah mengalami ini: (1) memvalidasi catatan yang ada, jika valid, alihkan ke halaman (2) memuat catatan untuk ditampilkan untuk pengguna. Jadi database dipukul untuk validasi dan untuk ditampilkan. Saya hampir menggunakan TempData untuk ini, tetapi ingin memeriksa opini. Saya suka metode Anda untuk menahannya.
— anonim
Akan lebih baik jika menggunakan mekanisme caching yang tepat dalam skenario ini.
— nicodemus13
3

Lihat pengontrol tanpa sesi sesi di MVC3. Ternyata, penggunaan sesi mencegah eksekusi paralel dari satu permintaan pengguna dan dengan demikian menyebabkan penurunan kinerja.

Karena tempdata menggunakan sesi secara default, Anda tidak akan dapat menggunakan fitur ini. Anda dapat beralih menggunakan cookie untuk tempdata, tetapi ini agak canggung (setidaknya untuk saya). Masih lebih bersih dari kondisi tampilan, jadi mungkin ini bukan masalah besar.

— aaimnr.dll
sumber
2
Anda benar tentang Pengontrol Tanpa Sesi dan TempData menggunakan Sesi. TAPI TUNGGU! Sesi BUKAN hal yang buruk dan Anda dapat mencampur dan mencocokkan Sessionless dengan pengontrol Sesi. Anda benar-benar menginginkan pengontrol Session_less_ saat Anda melakukan banyak panggilan AJAX ke server (dari browser). Ketika Anda hanya menekan satu halaman -pada-a-time- .. Anda tidak perlu menjadi tanpa sesi. Faktanya, itu TIDAK memberi Anda keuntungan ... karena Anda hanya menekan server SEKALI. Jadi mungkin untuk mencampur dan mencocokkan.
— Pure.Krome
2

Mengapa Anda memiliki keengganan seperti itu? Hal ini hanya membuat tugasnya dan membuatnya baik :)

Jika Anda tidak menyukainya karena tidak diketik dengan kuat, Anda selalu dapat membuat pembungkus yang akan memberi Anda antarmuka yang diketik dengan kuat.

— maxnk
sumber
2

Ini seperti menggunakan ViewData, artinya ini mungkin bukan risiko keamanan. Tetapi saya lebih suka menggunakan ViewData daripada TempData. Lihat di sini untuk perbandingan: http://www.squaredroot.com/2007/12/20/mvc-viewdata-vs-tempdata/

Bergantung pada desainnya, Anda selalu dapat menyimpan pengguna / keranjang atau apa pun yang Anda butuhkan dalam tempdata dalam database dan hanya memiliki bidang "IsReady" yang menunjukkan apakah sudah selesai atau belum, membuatnya dapat diperpanjang untuk nanti jika Anda ingin menerimanya ingat, bahwa orang dapat menutup browser mereka.

— Filip Ekberg
sumber
2
Catatan: artikel yang Anda tautkan adalah artikel terbaru untuk waktunya, tetapi hanya akurat untuk MVC1. TempData berubah cukup signifikan di MVC2.
— mikemanne
@mikemanne, ya. Tapi jawabannya dari akhir 2008. Tapi mungkin jawabannya harus diperbarui?
— Filip Ekberg
0

Semua jawaban yang bagus, pernahkah Anda melihat ini untuk menyampaikan pesan.

TempData dan Session bukanlah ide terbaik untuk arsitektur RESTful karena sebagian besar sesi disimpan dalam memori. Jadi ketika Anda ingin menggunakan server farm, sesi pengguna akan ada di satu server sementara permintaan mereka berikutnya dapat dikirim ke server lain.

Yang sedang berkata, lihat penggunaan TempData ini untuk menyampaikan pesan di sini.

http://jameschambers.com/2014/06/day-14-bootstrap-alerts-and-mvc-framework-tempdata/

Mungkin ini dapat diadaptasi untuk menggunakan pendekatan string kueri jika digunakan hanya untuk mengarahkan ke peringatan halaman lain.

— Warren
sumber
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.