Belirli bir MVVM uygulamasında bir çerçeve (Caliburn.Micro, vb.) Kullanmamayı nasıl seçebilirim?

28

Bir zamanlar sonunda inşa edilmiş ve konuşlandırılmış bir MVVM / WPF projesine başladım ve bunun için birçok Caliburn.Micro MVVM Çerçevesi üzerinde çalıştım. Gerçektir: Ben bitti değil bunun için Caliburn.Micro kullanarak ve (özellikle, sadece bazı MVVM terimleri ve tanımları kendim uygulamak sona erdi ViewModelBaseve RoutedCommandsınıflar).

Şimdi aynı satırlar boyunca biraz daha büyük bir projeye tayin edildim: “Tek Kullanıcı Zengin Müşteri Çevrimdışı Masaüstü Uygulaması”, yani, Caliburn.Micro'yu kullanmaya karar verdim. Ve işte benim "sorunum" başlıyor.

Başlığı "MVVM kullanıyorsanız bir çerçeveye ihtiyacınız var" diyen bu ünlü blog yazısında okudum :

“MVVM gibi bir şeyi bir çerçevesiz yapmayı denemek çok büyük bir iştir. Tonlarca yinelenen kod, tekerleği yeniden icat etmek ve insanları farklı düşünmeleri için yeniden eğitmek .

En azından bir çerçeveyle, yinelenen koddan kaçınırsınız ve umarım tekerleği yeniden icat etmek zorunda kalmazsınız - insanları yeniden eğitmeye odaklanmanıza izin verir. Yeniden eğitme kısmı genellikle kaçınılmazdır, ancak bir çerçeve işlemi kolaylaştıran sıhhi tesisat kodu ve yapısı sağlar. "

İlk okumamda hemfikir olurdum ama Caliburn.Micro (CM) ile olan asıl uygulamamdaki asıl deneyimim cansızlık ve oryantasyon bozukluğu olmak. Diğer bir deyişle, çerçeve süreci tam anlamıyla kolaylaştırmadı. Rob Eisenberg tarafından sağlanan sürekli yinelenen örnekleri gayrı (çok) gayri resmi dokümantasyonda okumak ve toplanmış olan örneklerden kullanım örneklerini ve bunların dayalı olarak çalışacak şekilde tasarlandıkları tamamen dolaylı sınıf ve arayüz ilişkilerini çıkarmaya çalışmak . yan etkiler, tecrübeli bir dahi olmadığınız sürece insanca imkansız görünüyor (rant için üzgünüm ama sanırım ne demek istediğimi biliyorsunuz).

Önemsiz bir senaryodan hiçbir zaman birlikte çalışmadığım ve sahip olamadığım bir sorunu çözen görünen IoC kaplarını içerdiği söylenmemelidir . Sorunum ve uygulama alanlarım hakkında düşünmek yerine, bu şeyleri öğrenmek için daha fazla proje saati harcamak istemiyorum. Sadece bir muz istemiştim ama CM bana bir sepet muz tutan bir goril (IoC) verdi.

Şimdi, uygulamak istediğim MVVM'ye özel derslerden sadece birkaçı oluşan MVVM çerçeveme geri dönmeyi düşündüğüm için, en azından burada bir şeyler kaybediyorsam CM'ye bir şans vermek istiyorum. sırf acemiliksizlik ve cehaletten, sadece basitçe işleri "yanlış yoldan" yapmak. Ve böylece soru şudur:

“Çerçeveler işleri daha kolay ve daha doğal hale getirir” diyen yaygın bir fikir birliği var, ancak bunun tam tersini yaşıyorsam, bu çerçeveyi kullanmamam gerektiği veya yanlış bir şekilde öğrenmeye çalıştığım anlamına mı geliyor? İlk başta bir çerçeve kullanmamam gerektiğine dair bir ipucu var mı? Veya basit MVVM gelişimi için CM'nin nasıl kullanıldığını anlamanın bir “doğru” yolu var mı?

frameworks wpf mvvm

— heltonbiker
kaynak

1

Şahsen, belirli davranışlarda kullanmak için her çerçeveden bir öğe seçip seçiyorum ve gerisini görmezden geliyorum. Örneğin, EventAggregatormesaj göndermek için Microsoft PRISM'leri , NotificationObjectViewModelBase'i ve RelayCommandkomutları için MVVM Light'larını kullanmayı seviyorum . Önemli olan, çerçevenin sizin için hangi problemleri çözeceğini belirlemektir ve sadece bu çözümleri kullanın. Tüm çerçeve kütüphanesini kullanmak zorunda kaldığınızı düşünmeyin.

— Rachel

@Rachel Caliburn.Micro ile bu yaklaşımı kullanmayı planlamıştım, ancak bir RelayCommanduygulama bulamadım (ICommand özelliklerine bağlanmak yerine doğrudan yöntemlerle yapılan sözleşmelere “bağlandığı” için).

— heltonbiker

Caliburn çerçevesini hiç kullanmadım, çünkü Görünümleri Model / ViewModel katmanına bağlamanın ne kadar yakın olduğunu beğenmedim. Sizin durumunuzda, RelayCommandeğer Caliburn Micro tarafından kullanılan, sizin için işe yaramazsa, başka bir kütüphaneden kullanamamanızın bir nedeni göremiyorum .

— Rachel

@Rachel “[caliburn] görünümü MVM katmanına ne kadar yakın bağlar” hakkında, tam olarak ne demek istiyorsun? Bu katmanları daha iyi, daha MVVM yöntemiyle bağlamanın "kalibre edilmemiş" yolu ne olurdu? (İçtenlikle soruyorum çünkü şu anda bilmiyorum).

— heltonbiker

Açıkçası Caliburn Micro'yu hiç kullanmadım, bu yüzden çerçevenin kötü bir yargıcı olduğumu hissediyorum. View'ın ilk olarak oluşturulduğu izlenimini elde ettiğimi ve View-First geliştirmesini sevmediğimden hoşlanmadığım bir yönü olan kodun arkasındaki nesnelere karar vermekten sorumlu olduğumu hatırlıyorum. Bir diğeri, kullanıcı arayüzünü iş katmanına çok fazla bağladığını düşündüğüm için, XAML bileşenlerini nasıl adlandırdığınıza dayanan otomatik bağlamalardı. Yine de çerçeve hakkında iyi şeyler duydum ve bence kaçınmamı tavsiye etmiyorum. Kendiniz deneyin ve

— Rachel

16

CaliburnMicro ve MVVMLight'ı denedim ve Caliburn kullanırken gerçekten ne hissettiğinizi hissediyorum, yalnızca eski Text = "{Bind PropertyName}" yerine Name = "PropertyName" komutunu kullanarak kontrolü özelliklere gerçekten bağlayabildiğine eminim. Sonunda Caliburn, bu büyülü şeyi yapmak için aşırıya kaçıyor, bir şeyler ters gittiğinde hata ayıklamak gerçekten zor, bir şeyi daha da kötüleştirmek için bir şeyi yapacak çok şeyleri var.

Ancak, MVVMLight'ı kullanırken incedir, onu kullandığınızda, MVVM Framework'ünüz gibi neredeyse% 100 olduğunu ve bazı özelliklerin de bulunduğunu fark edersiniz.

Bunun “çerçeveyi nasıl kullanmayacağınız” sorusuna cevap vermediğini biliyorum ama açıkçası o rotaya gitmenizi tavsiye edemem çünkü yanlış, aynı zamanda sadece kaybolduğunu düşünüyorum çünkü basit kullanmak yerine Tam özellikli çerçeveyi kullanıyorsunuz. birincisi.

— Kirie
kaynak

Öyleyse, en azından "Caliburn.Micro oryantasyon bozukluğu" nda MVVMLight'ı bir çeşit "tedavi" olarak kullanmayı denemem gerektiğini düşünüyor musunuz? Bu durumda kesinlikle bir göz atacağım.

— heltonbiker

@heltonbiker Kesinlikle, bir şans ver. MVVM Çerçevesinde size en azından iyi bir dayanak vermesi çok daha kolaydır.

— kirie

Çok fazla sihir olduğuna katılıyorum. Ac ve montaj geçmişinden geliyor sanırım. E bir şey sadece arka plandaki sihir nedeniyle bulmak için işe yaramaz. Hata ayıklamak imkansız ve performans sorunlarınız olduğunda çoğu zaman bu konuda kolayca yapamazsınız.

— rulolar

10

MVVM'nin ne olduğunu anlamak önemlidir. Yeniden biçimlendirmeniz gerekmeyen (bir JPEG dosyasını ayrıştırma veya belirli bir SQL veritabanı sunucusuna bağlanma) bazı paylaşılan işlevsellikler değil, zengin bir GUI uygulamasının nasıl seçileceği için bir kalıptır . Dolayısıyla, modelin uygulamanız basit ve anlaşılırsa, bir çerçeveden ziyade onu kullanmakta utanç duymanız gerektiğini düşünmüyorum.

Aslında, çerçeveler gibi kalıpların fikrinin çok daha ileri gittiğine inanıyorum. Her şeyin bir model olması için, bir çözüm sınıfının genel şekli olması gerekir. Bu böyle olduğu için, kalıpların onları kullanan sistemlere göre uyarlanması gerekeceği beklenir ve tek beden uyan herkese uygun bir kalıp kullanmaya çalışırsanız bunu yapamazsınız. Desen tasarımını uygulama tasarımcısına bırakmak ve mimarlıktan ziyade işlevselliği içeren kütüphaneler sağlamak çok daha yapıcı olacaktır.

— Michael
kaynak

2

Buna ek olarak, Microsoft tarafından sunulan MVVM (kutudan çıkan, WPF) çok eksik. Kendini (ve haklı olarak) tecrübeli geliştiriciler olarak düşünen programcılar için bile çok sinir bozucu. Sihirli dizeler, çalışma süresinde belirsiz istisnalar, bir grup radyo butonunu bir enuma bağlama gibi en temel şeyler stackoverflow.com/q/397556/168719 - çerçeveler ne yapabilir? Ya bu karmaşıklık seviyesini tekrarlamak zorundalar ya da üzerinde çok kalın bir soyutlama sağlamaya çalışıyorlar

— Konrad Morawski

2

@KonradMorawski WPF kendi başına MVVM değildir; WPF ile arkasındaki kodu yapabilirsiniz, ancak bu MVVM değil. Eğer WPF ve MVVM yapmak istiyorsanız, bir MVVM çerçevesi kullanmanız veya kendiniz bir tane uygulamanız gerekir.

— Andy

1

Elbette @Andy, ancak WPF olduğunu söylemek güvenli amaçlanan MMVM için. WPF ile yerleşik olarak gelen MVVM işlevselliğini kastediyorum. Hala arkasındaki kodları yapabileceğini biliyorum

— Konrad Morawski

@KonradMorawski WPF'yi MVVM ile birlikte kullanabilirsiniz ve inancınıza göre bu olasılığı göz önünde bulundurarak inşa ettiler, ancak WPF'ye yerleşik hiçbir MVVM'ye özgü işlevsellik yoktur. MVP'yi WinForms ile kullanabildiğiniz gibi, ancak WinForms bu modeli kullanmak için size özel bir şey sunmuyor.

— Andy

3

@Andy belki şimdi tanımları tartışıyoruz. Demek istediğim, MVVM'yi mümkün kılan tüm "yapıştırıcıların" zaten var olduğu - DataContext

— XAML'deki

7

WPF ile ilk deneyimim Caliburn.Micro'yu kullanıyor, bu yüzden bu muhtemelen çoğu geliştiriciden oldukça farklı. Hem WPF hem de Caliburn.Micro'yu WinForms'dan gelen oldukça dik bir öğrenme eğrisi olarak buldum, ancak her ikisiyle de bazı deneyimlerden sonra bunları çift olarak kullanmak için bir zevk buldum. Halen Caliburn.Micro'nun kullanılmadığı farklı bir organizasyonda çalışıyorum, kod temeli oldukça şişirilmiş ve gereksiz yere karmaşık hale getiren bir çoğul tesisat kodunun bir L olduğunu buluyorum.

Caliburn.Micro ile hata ayıklamayı zorlaştıran bazı yakalamalar olduğuna kesinlikle katılıyorum, ancak bir kez daha yaşadıklarında tekrar acı çekme ihtimalleri daha düşük. Artan geliştirme hızı, daha temiz ve daha yalın kod ve daha iyi MVVM'yi destekleyen genel çerçeve benim için daha değerlidir.

Caliburn.Micro ayrıca stok WPF'yi geçersiz kılmaz - sadece üstüne inşa eder, bu da isterseniz WPF özelliklerini kullanabileceğiniz ve eğer isterseniz Caliburn'ü birkaç bit ve parça için kullanabileceğiniz anlamına gelir. Bu, TypeScript ve JavaScript'in aklımda bir arada var olmalarına benzer.

Ben kesinlikle Caliburn.Micro'yu, şansım olsa gelecekte üzerinde çalışacağım yeni bir WPF projesinde kullanırdım.

— Ross
kaynak

3

Cevabınız için teşekkürler. İki yıl sonra, mükemmel Mark Seeman'ın "DI in .NET" kitabından öğrendiğim Bağımlılık Enjeksiyon Konteynerleri kavramını anladıktan sonra bu çerçeveleri "kabul etmeyi" çok daha kolay buldum.

— heltonbiker

1

Caliburn.Micro’daki sıkıntıdan dolayı buraya gelen herkes için, şu çerçeveye bir bakın: Stylet

Caliburn.Micro'dan esinlenildi, ancak olanlar hakkında sizi şaşırtan sihrin çoğunu ortadan kaldırması dışında. Ek olarak, teknik jargondan geçmek istediğinizi varsaymadan, belgeler daha sade bir dille yazılmıştır. Yeni başlayanlar için çok daha iyi.

Ayrıca, Stylet ViewModel-First yaklaşımını benimsemiştir. Caliburn.Micro ve birçok başka çerçeve, bazı garip problemlerle birlikte gelen View-First yaklaşımını benimsemiştir. SOLID ilkeleri ve desenli kod konusunda zaten çok iyiyseniz, mantığınızın görünümü değil, sistemi kullanması gerektiği perspektifini aldığı için ViewModel-First yaklaşımını daha doğal bulabilirsiniz.

— JamesHoux
kaynak