MVVM ve servis düzeni

MVVM desenini kullanarak bir WPF uygulaması inşa ediyorum. Şu anda, görünüm modellerim modelleri (görünüm modeliyle nasıl ilgili değil) almak ve bunları görünüm modellerine dönüştürmek için hizmet katmanını çağırıyor. Viewmodel için gerekli hizmeti geçmek için yapıcı enjeksiyon kullanıyorum.

Kolayca test edilebilir ve birkaç bağımlılığa sahip görünüm modelleri için iyi çalışır, ancak karmaşık modeller için viewModels oluşturmaya çalıştığımda, içine enjekte edilmiş çok sayıda hizmet içeren bir yapıcıya sahibim (her bağımlılıkları ve mevcut tüm değerlerin listesini almak için bir tane) örneğin bir itemSource kaynağına bağlamak için). Böyle birden çok hizmeti nasıl ele alacağımı merak ediyorum ve yine de kolayca test edebileceğim bir görünüm modeline sahibim.

Birkaç çözüm düşünüyorum:

1. Arabirim olarak kullanılabilir tüm hizmetleri içeren bir hizmet singletonu (IServices) oluşturma. Örnek: Services.Current.XXXService.Retrieve (), Services.Current.YYYService.Retrieve (). Bu şekilde, içinde tonlarca hizmet parametresi olan büyük bir kurucum yok.

2. ViewModel tarafından kullanılan hizmetler için bir cephe oluşturma ve bu nesneyi viewmodelimin kasasına geçirme. Ama sonra, her karmaşık görünüm modelim için bir cephe oluşturmam gerekecek ve biraz fazla olabilir ...

Sizce bu tür mimariyi uygulamanın "doğru" yolu nedir?

Aslında, bu çözümlerin her ikisi de kötü.

Arabirim olarak kullanılabilir tüm hizmetleri içeren bir hizmet singletonu (IServices) oluşturma. Örnek: Services.Current.XXXService.Retrieve (), Services.Current.YYYService.Retrieve (). Bu şekilde, içinde tonlarca hizmet parametresi olan büyük bir kurucum yok.

Bu, esasen bir anti-desen olan Servis Bulucu Kalıbıdır . Bunu yaparsanız, görünüm modelinin özel uygulamasına bakmadan gerçekte neye bağlı olduğunu artık anlayamayacaksınız, bu da test etmeyi veya yeniden düzenlemeyi çok zorlaştıracaktır.

ViewModel tarafından kullanılan hizmetler için bir cephe oluşturma ve bu nesneyi viewmodelimin kasasına geçirme. Ama sonra, her karmaşık görünüm modelim için bir cephe oluşturmam gerekecek ve biraz fazla olabilir ...

Bu bir anti-desen değil, bir kod kokusu. Esasen bir parametre nesnesi oluşturuyorsunuz , ancak PO yeniden düzenleme modelinin noktası, sık ve çok farklı yerlerde kullanılan parametre kümeleriyle uğraşmaktır , oysa bu parametre yalnızca bir kez kullanılır. Bahsettiğiniz gibi, gerçek bir fayda sağlamak için çok fazla kod şişmesi yaratacak ve çok sayıda IoC kapsayıcısı ile hoş oynamayacaktır.

Aslında, yukarıdaki stratejilerin her ikisi de genel meseleyi gözden kaçırmaktadır, yani görünüm modelleri ve hizmetleri arasında çiftleşme çok yüksektir . Basitçe gizleme bir hizmet bulucuda bu bağımlılıkları veya parametre nesnesi aslında vermez değiştirmek görünüm modeli bağlıdır kaç diğer nesneler.

Bu görünüm modellerinden birini nasıl test edeceğinizi düşünün. Kurulum kodunuz ne kadar büyük olacak? Çalışması için kaç şeyin başlatılması gerekiyor?

MVVM ile başlayan birçok insan , tüm ekran için temel olarak yanlış yaklaşım olan görünüm modelleri oluşturmaya çalışır . MVVM tamamen kompozisyonla ilgilidir ve birçok işlevi olan bir ekran, her biri sadece bir veya birkaç dahili modele / hizmete bağlı olan birkaç farklı görünüm modelinden oluşmalıdır. Birbirleriyle iletişim kurmaları gerekiyorsa, bunu pub / sub (mesaj komisyoncusu, olay otobüsü vb.)

Aslında yapmanız gereken, daha az bağımlılığa sahip olmaları için görünüm modellerinizi yeniden düzenlemektir . Daha sonra, toplam bir "ekrana" ihtiyacınız varsa, daha küçük görünüm modellerini toplamak için başka bir görünüm modeli oluşturursunuz. Bu toplu görüntüleme modelinin kendi başına çok fazla bir şey yapması gerekmediğinden, anlaşılması ve test edilmesi de oldukça kolaydır.

Bunu düzgün bir şekilde yaptıysanız, sadece koda bakmaktan açıkça anlaşılmalıdır, çünkü kısa, özlü, spesifik ve test edilebilir görünüm modellerine sahip olacaksınız.

Bu konuda bir kitap yazabilirdim ... aslında öyleyim;)

Öncelikle, bir şeyler yapmak için evrensel olarak "doğru" bir yol yoktur. Başka faktörleri de dikkate almalısınız.

Hizmetlerinizin çok ince taneli olması mümkündür. Belirli bir Viewmodel veya hatta ilgili ViewModels kümesinin kullanacağı arabirimi sağlayan Hizmetleri Cephelerle Sarmak daha iyi bir çözüm olabilir.

Daha basit, hizmetleri tüm görünüm modellerinin kullandığı tek bir Cephe'ye sarmak olacaktır. Tabii ki bu potansiyel olarak ortalama senaryo için pek çok gereksiz fonksiyonla çok büyük bir arayüz olabilir. Ancak, sisteminizdeki her iletiyi işleyen bir ileti yönlendiricisinden farklı olmadığını söyleyebilirim.

Aslında, sonunda pek çok mimarinin evrim geçirdiğini gördüğüm, Olay Toplayıcı deseni gibi bir şeyin etrafına inşa edilmiş bir mesaj veri yolu. Test sınıfınız sadece EA ile bir dinleyici kaydettirdiği ve buna karşılık olarak uygun olayı başlattığı için test yapmak kolaydır. Ancak bu, büyümesi zaman alan ileri bir senaryodur. Ben birleştirici cephe ile başlayın ve oradan gidin diyorum.

Neden ikisini birleştirmiyorsun?

Bir cephe oluşturun ve görünüm modellerinizin kullandığı tüm hizmetleri koyun. Daha sonra kötü S kelimesi olmadan tüm görünüm modelleriniz için tek bir cepheye sahip olabilirsiniz.

Veya yapıcı enjeksiyonu yerine özellik enjeksiyonu kullanabilirsiniz. Ama sonra, bunların düzgün bir şekilde enjekte edildiğinden emin olmanız gerekir.