Winforms-MVP ve WPF-MVVM'deki istisnaların son kullanıcıya bildirilmesi

Question

Winforms-MVP'nin yarısı boyunca aşağıdaki özel durum işleme stratejisini tasarladım. Giriş parametresi olarak bir temsilci alarak birkaç Execute yöntemiyle temel soyut Presenter sınıfım var (imzalar değişir). Görünüş ve Sunum arasındaki etkileşim, IView'de tanımlanan olaylar (giriş) ile yapılır ve Görünüm tarafından uygulanan ve uygulanan IView'de tanımlanan kamu özellikleri (çıktı) veya çağrı yöntemleri belirleyerek yapılır. Sunucudaki her olay işleyici, somut gerçekleme sağlayan Uygulama yöntemlerinden birini çağırır.

Yürütme yönteminde, oluşabilecek çok kesin istisnalar için (özellikle yaygın olarak kullanılan dış bileşenlerde bazı sorunlar nedeniyle) birkaç yakalama bloğum var. Bu istisnaların her biri, mevcut işlemin yürütülmesini durdurur, günlüğe kaydedilir ve View'ın yöntemlerini çağırarak kullanıcıya anlamlı bir açıklama ile gösterilir.

Çok uzun bir süre önce (aslında çok uzun bir süre önce değil) İlk bakışta MVP ile çok ortak gözüken WPF-MVVM'yi öğrenmeye başladım. İstisnai taşıma stratejisi ile ilgili bazı pratik öneriler (temelde kullanıcıyı problemler hakkında bilgilendirmek) aradım, ama bu soruları genel olarak aramak zor. Yani, çok şey söylendi, ama esas olarak prensipte. App.xaml.cs dosyasında işlenmemiş istisnaların 20'den fazla örneğini buldum, hepsi çok güzel, ama içtenlikle söyle - eğer uygulamanızı kilitleyebileceğiniz kesin istisnaları biliyorsanız, bunları işlemezseniz biraz önce (uygulamanızı kapatmaya zorlanacak olsanız bile)? Tüm olası istisnaları yakalamanın bir hayranı değilim. Ağ sorunları, geçici veritabanı kullanılamazlığı vb. Nedenlerle oluşan bir çok istisna, olağan bir kullanıcıya isteğini tekrar etme şansı veren korkutucu hata simgeleri olmadan uygulamayı kapatmadan ele alınmalıdır.

Bir deneme olarak, daha önce anlattığım gibi neredeyse aynı şeyi denedim - Özel durumlar geçişi için ViewModel'de etkinlikler oluşturdum ve onlara abone oldum. Ancak, açık konuşmak gerekirse, bu şekilde beni ürpertiyor.

(Bu çok uzun bir konuşmaydı, biliyorum) Soru: MVVM kullanırken kullanıcıyı bilgilendirmekle ilgili istisnaları nasıl ele alıyorsunuz? Hayır, şimdilik sadece veri doğrulama ile ilgilenmiyorum. MVP hakkında herhangi bir eleştiri ve/veya danışma da kabul edilir.

Answer 1

Biz WPF uygulamalarında hata koşullarının farklı türleri için farklı stratejilerin bir çift var.

Kodun, kullanıcıya bildirmeden işlem yapabileceği ve devam edebileceği tahmin edilen hatalar için, normal Try Catch bloklarını yaparız.

Öngörülen, ancak kullanıcılar açısından bir hatayla sonuçlanan hatalar için, ViewModels'ımızdaki bildirim çubuklarına benzer şekilde şablonlanan View ürünümüzü içeren bir ItemsControl'e bağlı bir Bildirimler koleksiyonunu görüntülüyoruz. Firefox/IE/Krom.Her bildirim, belirli bir süre için görünebilmeleri veya kullanıcı tarafından açıkça kapatılabilmeleri için bir gösterim süresi özelliğine (Bildirimler koleksiyonu bir dağıtım zamanlayıcısı kullanılarak kendi kendini budamadır) ve görünümde bir kapatma düğmesine sahiptir. Bu modelle ilgili güzel olan şey, Tamamlama mesajları, uyarılar ve istisnalar için kullanılabileceği ve istisna olarak ortaya çıkamayan, ancak yine de kullanıcılar açısından hala hata koşulları olan bazı koşulların kullanılabilmesidir. Bildirimler, kullanıcıların iş akışını kesintiye uğratmadıkları için genellikle ileti kutusu için iyi bir yer değiştirir.

Beklemediğimiz hatalar için, kullanıcıların analiz için destekimize gönderebilmeleri amacıyla tüm ayrıntıları yakalamak için Red Gate SmartAssembly kullanın. Bizim görüşümüz, beklemediğiniz istisnalar sonrasında uygulamanızı yakalamak ve devam ettirmek için çok riskli bir stratejidir. Beklenmeyen bir istisnadan gelen yığın bozulmaz ve uygulamanız hatadan sonra tutarsız bir durumda kalır (garip bir UI'den veri bozukluğuna kadar herhangi bir şey) ve tahmin etmek imkansız olan yan etkiler olabilir. Bir uygulama çökmesine sahip olmak harika bir kullanıcı deneyimi değil, ancak uygulama tarafından yok sayılan bir hatanın neden olduğu beklenmedik bir durum nedeniyle verileri bozması önemli ölçüde kötü bir deneyim. Stratejimiz, çarpışma hakkında çok fazla ayrıntı yakalamaktır, böylece kullanıcı sorunu ele alma konusunda ciddi olduğumuzu bilir ve gelecekteki bir güncellemede sabit/yakalanır - sadece potansiyel olarak daha kötü olan sorunları devam ettirmek yerine.

Answer 2

Kabul ediyorum

temelde çok geç, çünkü app.xaml.cs içinde istisnalar işlenmesini bırakarak iyi değil!

Potansiyel bir istisnanın nispeten yüksek olduğu işlemler (dosya yönetimi, ağ IO) için, istisnaları aktif bir şekilde yakaladığınızdan emin olun. dosya bulunamadı, bazı uzun süren sorununu işaret hataları için

1. , ağ sorunları, örneğin bir 'ErrorState' Maddı geçici sorunlar için
2. maruz: İki yoldan birini kullanarak görünümüne bu açığa örneğin, bir olay ortaya çıkarın.