ASP.NET MVC - TempData - İyi veya kötü uygulama

96

AcceptVerbsASP.NET MVC'deki form girişleriyle ilgilenmek için Scott Gu'nun Preview 5 blog gönderisinde ayrıntılı olarak verilen yöntemi kullanıyorum :

  • Kullanıcı GET aracılığıyla boş bir form alıyor
  • Kullanıcı doldurulan formu POST yoluyla aynı eyleme gönderir
  • İşlem, verileri doğrular, uygun işlemi yapar ve yeni bir görünüme yönlendirir

Bu yüzden kullanmak zorunda değilim TempData. Bununla birlikte, şimdi bu sürece bir 'onayla' adımı eklemem gerekiyor ve bunun kullanımını gerektiriyor gibi görünüyor TempData.

Bazı nedenlerden dolayı kullanmaktan hoşlanmıyorum TempData- bunun etrafında tasarlanacak bir şey.

Bu hiç de geçerli bir endişe mi yoksa uyduruyor muyum?

asp.net-mvc  tempdata 
— anonim
kaynak
1
'Onayla' adımınızı bir javascript iletişim kutusu yapmayı düşünün. Daha az sunucu gidiş dönüşü ve bu problemle karşılaşmazsınız.
— ajma

Yanıtlar:

26

Geçici veriyi, kullanıcıyı bilgilendirmek için bir tut ve unut mekanizması olarak düşünüyorum. Onlara son zamanlarda yaptıkları bir şeyi hatırlatmak harika, ancak bazı kullanıcı süreçlerinde bunu gerekli bir adım haline getirmekte tereddüt ediyorum. Nedeni, sayfayı yenilemeleri durumunda gitmiş olacağına inanıyorum. Sanırım ne kadar güvenilir olduğu çok iyi tanımlanmadığı için kullanmakta da tereddüt ediyorum.

Sorunun, işlemin onaylama adımından önce başka bir sayfaya yönlendirilmesi olup olmadığını merak ediyorum. Merak ediyorum, bunun yerine ilk gönderildikten sonra, onaylama iletişim kutusunu oluşturmak için yeterli işlem yapıp, ardından onay sorusunu içeren orijinal sayfayı geri döndürebilir misiniz? Doğrulama kuralı, doğrulama adımının gerçekleştirilip gerçekleştirilmediğini kontrol etmesi dışında, doğrulamayı nasıl yapabileceğinize benzer (diğer doğrulama geçene kadar onay kullanıcı arayüzü gizlenir).

— Frank Schwieterman
kaynak
77

TempData'dan hoşlanmanıza gerek yok ... Ancak doğru kullanılmazsa, kesinlikle kötü tasarımın bir göstergesi olabilir. RESTful URL'leri kullanıyorsanız, TempData, iletileri POST Eylemlerinizden GET Eylemlerinize aktarmak için en iyi uygulamadır. Bunu düşün:

URL Products / New adresinde bir formunuz var. Formu doğrulayan ve Ürünü oluşturan Ürünlere Gönder / Oluştur formu, Başarılı Olduğunda Denetleyici URL Ürünlerine / 1 yönlendirir ve hata durumunda Ürünlere / Yeni'ye Hata Mesajlarını görüntülemek için yeniden yönlendirir.

Ürünler / 1, ürün için yalnızca standart GET eylemidir, ancak ekin başarılı olduğunu belirten bir mesajın görüntülenmesini istiyoruz. TempData bunun için mükemmeldir. Mesajı Post Controller'daki TempData'ya ekleyin ve görünüme bir miktar if mantığı koyun ve yaptınız.

Başarısızlık durumunda, formCollection'a girilen değerleri ve bir dizi hata Mesajını Eylem Sonrası'nda TempData'ya ekliyorum ve ilk Eylem Prodcuts / Yeni'ye yönlendiriyorum. Form girişlerini herhangi bir hata mesajıyla birlikte önceden girilen değerlerle doldurmak için görünüme mantık ekledim. Bana güzel ve temiz görünüyor!

— JasonD
kaynak
1
Doğrudan sayfasına geri dönerken neden bu ekstra işi yapasınız Products/New? Ne değer Products/Createkatar?
— mpen
2
@Mark, Ürünler / Oluştur özelliğini kullanmak, kullanıcının geri gönderme yoluyla eylemi tamamlaması, ardından daha sonra yenilemede (veya bir yer imi ve iade) yanlışlıkla eylemi yeniden tamamlaması durumu önler. Daha fazla bilgi için, bkz en.wikipedia.org/wiki/Post/Redirect/Get
— ehdv
3
@ehdv: Ama gerçekten mi? Başarı durumunda başka bir sayfaya yönlendirir, başarısız olduğunda form hatalarını göstermeli ve herhangi bir işlem yapılmamalı, bu nedenle zarar verilmemelidir. Bu sadece sık sık istediğim can sıkıcı "yeniden göndermek istediğinizden emin misiniz" mesajını engeller. Sanırım bu sizin tasarımınıza bağlı, yani ne demek istediğinizi görebiliyorum.
— mpen
31

TempData'yı kullanmadan önce tereddüt etseniz iyi olur. TempData oturumda saklanır ve aşağıdaki durumlarda bunun sizin için etkileri olabilir:

  1. Şu anda sitenizde oturum kullanmıyorsunuz
  2. Yüksek işleme hızına ölçeklenmesi gereken bir sisteminiz var, yani oturum durumundan tamamen kaçınmayı tercih edersiniz
  3. Çerez kullanmak istemiyorsunuz (MVC'nin şu anda çerezsiz oturumları ne kadar iyi desteklediğini bilmiyorum)

Sitenizin yüksek kullanılabilirliğe sahip olması gerekiyorsa, oturum durumunu uygulamaya yönelik ek hususlar vardır, ancak bunların tümü çözülebilir sorunlardır.

— John Rayner
kaynak
16
Varsayılan sağlayıcı olmasına rağmen, TempData'nın oturumda depolanması gerekmez - muhtemelen bu yüzden yöntem belgesinde değildir. Özel bir sağlayıcının nasıl yazılacağına bir örnek olarak orada bir çerez sağlayıcısı da var.
— FinnNk
3

İlk olarak TempData ["model"] için kontrol eden ve bunu döndüren bir GetModel yöntemim var. Aksi takdirde GetModel, uygun verileri veritabanından yükler.

Aynı model verilerini gerektiren farklı bir görünüm döndürmem gereken bir eylemim olduğunda veritabanından fazladan bir yük tasarrufu sağlıyor.

— Todd Smith
kaynak
Evet, bununla karşılaştım: (1) bir kaydın var olduğunu doğrulayın, eğer geçerliyse, kullanıcı için görüntülemek üzere sayfa (2) yükleme kaydına yeniden yönlendirin. Böylece veritabanı doğrulama ve görüntüleme için vurulur. Bunun için neredeyse TempData kullanıyorum, ancak görüşleri kontrol etmek istiyordum. Yine de, yönteminin onu kontrol etmesini seviyorum.
— anonim
Bu senaryoda uygun bir önbelleğe alma mekanizması kullanmak daha iyi olacaktır.
— nicodemus13
3

Check out Oturumsuz denetleyicileri MVC3 içinde. Oturumu kullanmanın tek bir kullanıcının isteklerinin paralel olarak yürütülmesini engellediği ve dolayısıyla performansın düşmesine yol açtığı ortaya çıktı.

Tempdata varsayılan olarak oturum kullandığından, bu özelliği kullanamazsınız. Tempdata için tanımlama bilgilerini kullanmaya geçebilirsiniz, ancak bu biraz garip (en azından benim için). Yine de viewstate'den daha temiz, bu yüzden belki de o kadar da önemli bir sorun değil.

— aaimnr
kaynak
2
Oturumsuz Denetleyiciler konusunda haklısınız ve TempData Oturumu kullanıyor. FAKAT BEKLE! Session kötü bir şey DEĞİLDİR ve Sessionless ile Session kontrol cihazlarını karıştırıp eşleştirebilirsiniz. Sunucuya (tarayıcıdan) çok sayıda AJAX çağrısı yaparken gerçekten Session_less_ denetleyicileri istiyorsunuz. Her seferinde bir sayfaya vurduğunuzda .. oturumsuz olmanıza gerek yok. Aslında, bu size herhangi bir fayda sağlamamalı ... çünkü sunucuya sadece BİR KEZ vuruyorsunuz. Böylece karıştırmak ve eşleştirmek mümkündür.
— Pure.Krome
2

Neden bu kadar tiksiniyorsun? Bu şey basitçe işini yapmak ve onu iyileştirmek :)

Eğer güçlü bir şekilde yazılmadığı için hoşunuza gitmiyorsa, etrafına her zaman güçlü yazılmış bir arayüz sağlayacak bir sarmalayıcı yapabilirsiniz.

— maxnk
kaynak
2

ViewData kullanmak gibi, yani muhtemelen bir güvenlik riski değil. Ama ben TempData yerine ViewData kullanmayı tercih ederim. Karşılaştırma için burayı kontrol edin: http://www.squaredroot.com/2007/12/20/mvc-viewdata-vs-tempdata/

Tasarıma bağlı olarak, her zaman kullanıcıyı / sepeti veya ihtiyaç duyduğunuz her yeri veritabanındaki tempdata içinde saklayabilir ve tamamlanmış olup olmadığını gösteren bir "Hazırda" alanına sahip olabilirsiniz, böylece içeri almak istiyorsanız daha sonra genişletilebilir hale getirebilirsiniz. insanların tarayıcılarını kapatabileceğini unutmayın.

— Filip Ekberg
kaynak
2
Not: Bağlandığınız makale, zamanı için günceldi, ancak yalnızca MVC1 için doğrudur. TempData, MVC2'de oldukça önemli ölçüde değişti.
— mikemanne
@mikemanne, evet. Ancak yanıt 2008'in sonlarından. Ama belki yanıt güncellenmeli?
— Filip Ekberg
0

Tüm güzel cevaplar, mesajları iletmek için buna bir göz attınız mı?

Çoğu oturum bellekte depolandığından, TempData ve Session RESTful mimarileri için en iyi fikir değildir. Dolayısıyla, bir sunucu grubu kullanmak istediğinizde, kullanıcıların oturumu bir sunucuda bulunurken, sonraki istekleri başka bir sunucuya gönderilebilir.

Bununla birlikte, mesajları buraya iletmek için bu TempData kullanımına bir göz atın.

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

Mabye bu, yalnızca başka bir sayfa uyarılarına yönlendirme için kullanılırsa, bir sorgu dizesi yaklaşımını kullanmak üzere uyarlanabilir.

— Warren
kaynak
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.