MVVM Açıklama

İlk WPF uygulamamızı yazmak üzereyiz ve MVVM modelini tanıyoruz. Birçok Winform uygulaması geliştirdik ve bizim için çok başarılı bir mimariye sahibiz. Bu mimariyi çevirmekte veya mimarimizin bazı parçalarının MVVM modeline nerelerde uyduğunu belirlemekte biraz sorun yaşıyoruz.

Tarihsel olarak bir Gui (ana exe) daha sonra bir BusinessLogic dll iletişim kurar. BusinessLogic bir web hizmeti aracılığıyla bir DAL dll ile iletişim kurar ve DAL DB ile etkileşime girer. DAL, BusinessLogic ve GUI aynı BusinessObjects dll referans.

Asya Mimarisi

MVVM'ye geçişin bir kısmı oldukça basittir. Gui'miz hala görüşlerini içerecek, BusinessOjbects'imiz yine de modeli içerecek ve DAL'ımız DB ile hala etkileşime girecek (bunları uygulama teknolojisi değişebilir).

Emin olmadığımız şey BusinessLogic bileşenimizdir. Tarihsel olarak bu, GUI'nin görünümlerde denetimleri doldurması için çağrılacak işlevler (örneğin, Müşteri nesnelerinin listesini veya tipik CRUD işlevlerini döndürecek GetCustomerList) sağlar.

Sahip olduğumuz ana asmak, MVVM modelinin ViewModels'i barındırmak için ek bir bileşen gerektirip gerektirmeyeceği veya sadece düşüncemizi değiştirip BusinessLogic bileşenimiz olarak kullandığımızı ViewModels'e geçirip geçirmeyeceğimizdir?

BusinessLogic bileşenimiz ViewModels'i temsil ediyor mu?

architecture mvvm

— user7676
kaynak

Bu biraz sorun arayan bir çözüm gibi geliyor. MVVM'ye geçmenizin zorlayıcı bir nedeni var mı? Modelin hayranıyım ama önceki çözümünüz çalışmıyor muydu? Görünüm modeli denetleyici bir sunucu gibidir. Sunum mantığını içerir ve veri bağlama yoluyla verileri yüzeyler. İş mantığınızı bilmeli ve bu seviyeye ulaşabilmelidir, ancak iş mantığını görünüm modelinin içine daraltmam.

— Jeremy Likness

Yanıtlar:

Genel olarak, iş mantığını görünüm modeli katmanına yerleştirmezdim. Ancak "İş Mantığı" terimi yanıltıcıdır.

Eric Evans iş mantığının iki kategoriye ayrıldığı bir model kullanıyor

Alan adı mantığı - Çözdüğünüz asıl sorun alanıyla ilgili mantık
Uygulama mantığı - Bir uygulama oluşturduğunuz gerçeğiyle ilgili mantık

Muhasebe uygulaması örneğinden bahseder. Hesaplar, postalar, vergi hesapları vb. İle ilgili kurallar, alan kuralları, muhasebe alanıyla ilgili kurallardır. CSV içe / dışa aktarma mantığının muhasebe alanıyla ilgisi yoktur. Bu kurallar yalnızca bir yazılım uygulaması geliştirdiğimiz için mevcuttur. Bunlar uygulama mantığına örnektir.

Alan adı kuralları ASLA görünüm modeli katmanına girmemelidir. MVVM modelini izliyorsanız, etki alanı kuralları, sorgulamadan model katmanına gider.

CSV içe / dışa aktarma gibi uygulama kuralları görünüm modeli katmanına girebilir . Ancak kişisel olarak, bunu ayrı bir uygulama mantığı katmanına ayırmayı tercih ederim.

Görünüm Modeli çok basit olmalıdır. İlgili modelde görünümün ihtiyaç duyduğu verilere bakmak, görünüm değiştiğinde modeli güncellemek, modeldeki olayları dinlemek ve bu olayları görünüme yaymak, model sahne arkasında güncellendiğinde görünümün güncellenmesine izin vermek (uygunsa).

Şahsen, görünüm modeli katmanının sadece bir tür mantık, sunum mantığı içerdiğinden emin olurum.

— Pete
kaynak

Mükemmel cevap. ViewModel'in yalnızca Sunum mantığı içerdiğinden emin olmaktan hoşlanıyorum. Eric Evans noktanızla ilgili herhangi bir bağlantı ekleyebilir misiniz?

— user7676

Bir bağlantı bulabileceğimden şüpheliyim, çünkü Domain Domain Driven Design adlı kitabından aldığımı düşünüyorum. Her neyse, etki alanı ve uygulama mantığı arasındaki farklılığın mükemmel bir örneği olduğunu düşünüyorum. Burada kitap hakkında daha fazla bilgi books.google.dk/books/about/…

— Pete

Evet.

İş mantığı katmanı VM katmanı tarafından temsil edilir. Yani sadece zihinsel modelinizi taşıyın.

Zihinsel model geçişinize yardımcı olmak için, hafif bir nüans GUI (View) nesnelerinin VM katmanındaki nesnelere bağlanması gerektiğidir. Bu ciltleme, | Görünümün artık başka bir şey almak için "arama yapan" katman olmadığı anlamına gelir. Veri alma çağrısı bunun yerine VM'den gelecek.

Daha iyi açıklamak için: Evet, Görünüm yapacak bir nesnenin, çağrıyı yapacak şeylerin sırasını tetiklemesi için değişmesi gerekecektir. Ancak Görüş çağrıyı kendisi yapmaz. Ve bu durumda, bir düğme tıklamasının Görünüm içindeki bir şeye eşdeğer olduğunu düşünüyorum, ancak yine de arama yapmıyorum.

İlk durumda, bu View nesnesi bir VM nesnesine bağlanır. VM, bağlı nesne üzerinde özellik değiştirilmiş bir olay dinliyor olmalıdır. Nesne değiştirme olayı daha sonra Model çağrısı yapmak için bir VM fonksiyonuna bağlanabilir.

İkinci durumda (button click olayı), change (click) olayı VM tarafından maruz bırakılan bir işlev çağrısına bağlanabilir.

Her iki durumda da, her zaman VM'yi sıralayan ve daha sonra Modeli DAL / DB'yi çağıran bir olay.

Bazı WinForm kodu doğrudan DB katmanı WinForm GUI arkasından kod katmanı için arama yapmak için kullanılır çünkü onu getirmek. Bu yaklaşım, MVVM'nin sağladığı ayrımı bozar.

Onay için teşekkürler. Görünüm'ün ViewModel ile nasıl etkileşime girdiğinin nüansını anlıyoruz ve ciltleme modeline bağlı kalarak "çağrı" yı bırakacağız.

— user7676

Bu cevabın oyu kaybettiğini fark ettim. Düşürücünün neden hakkında yorum yapıp yapmayacağını merak ediyorum? Ya da belki de bu bakış açısını paylaşmazlarsa kendi cevaplarını ekleyin.

— user7676

İş mantığı katmanının VM katmanı tarafından temsil edildiğini kabul ediyorum, ancak cevabınızın bazı bölümlerinin kafa karıştırıcı olabileceğini düşünüyorum. ViewTabaka ViewModel veya Model görsel bir temsilidir olabilir, bu yüzden ziyade tıklama etkinlik VY'de bir işlev çağrısına kablolu diyerek gönderme amaçlı olduğu daha iyi tanım VM Komutanlığı söylemek olurdu bir düğme gibi işlenen alır Görünüm katmanı. Ayrıca, ben genellikle benim uygulama akışı tipik gider böylece doğrudan DAL erişebilir olmak benim Model katmanında sevmiyorum VM -> DAL -> DB, nerede VMve DALher iki kullanacağım düz Modelveri nesneleri.

— Rachel

Bu cevaba katılmıyorum. ViewModel görünümün modelidir, iş mantığını değil görünüm mantığını içerir. ViewModels sunum katmanının bir parçası

— simoraman

@simoraman - MVPVM kalıbı önerdiğinizle uyumlu. Bence MVPVM iyi bir model, ancak küçük uygulamalar için biraz ağır. Düşüncelerinizi bir yanıta koymanızı ve bu soruya katkıda bulunmanızı gerçekten öneririm.

Eğer BusinessLogic dll yerine ViewModel katman ile değiştirilmesi doğru olduğunu, ancak karşılaşacağınız en büyük fark View / UI katman ViewModel / BusinessLogic katman ile etkileşim olduğunu düşünüyorum.

WinForms'da GUI uygulamanızdır ve uygulama akışından sorumludur. WPF / MVVM'de, ViewModels'ınız size uygulamanızdır ve GUI, ViewModels ile etkileşim kurmak için sadece kullanıcı dostu bir arayüz haline gelir.

Örneğin, WinForms ile bir DataGrid ve bir Button olabilir ve bu Button'ı tıklattığınızda BusinessLogicLayer.GetProducts(), ortaya çıkan Product nesnelerini DataGrid'e yükleyip yüklersiniz.

WPF ile, bir ObservableCollection<Products>ve bir içeren bir ViewModeliniz olur ICommand GetProductsve komutu yürütmek DAL'yi çağırır ve ürün koleksiyonunu yükler. Ancak bunun için kullanıcı dostu bir arayüz sağlamak için, Ürünler koleksiyonu için bir DataGrid ve GetProducts komutu için bir Düğme kullanarak ViewModel'inizi oluşturan bir Görünüm oluşturacaksınız.

Aslında blogumda Winforms'tan WPF'ye geçerken zihniyet değişikliği hakkında blogum için oldukça yeni bir yazı yazdım ve bence farkı özetlemenin en iyi yolu şu resimlerle:

— Rachel
kaynak

GlenH7 ile hemfikirim, bu WPF ile başlayan biri için iyi bir cevap. View ve ViewModel arasındaki etkileşimin paradigma değişimini elde ediyoruz, bu yüzden bu gerçekten sorduğum soruya konu değildi.

— user7676