Model Görünümü View-Model, Microsoft tarafından XAML ve .NET dillerini kullanan .NET platformlarındaki olay odaklı programlamayı, özellikle Windows Presentation Foundation (WPF) ve Silverlight'ı destekleyen UI geliştirme platformlarını hedeflemek için geliştirilmiştir. O zamandan bu yana Angular, Knockout ve ExtJS gibi birçok Javascript çerçevesi bu modeli benimsedi.
Çoğu yazılım modeli gibi, MVVM de uygun kullanımlarına ve kötüye kullanımlarına sahiptir. Hangi koşullar altında MVVM kullanımı uygundur? Ne zaman tavsiye edilmez?
MVVM, daha "geleneksel" bir geliştiriciden (ör. İş mantığına yönelik) farklı gereksinimleri olan bir kullanıcı deneyimi (UXi) geliştiricisinin bulunduğu modern UI geliştirme platformlarını (Windows Presentation Foundation veya WPF ve Silverlight) hedef almaktadır. arka uç geliştirme). MVVM'nin View-Model'i “temel olarak steroidler üzerinde bir değer dönüştürücüsüdür”, yani View-Model, Modeldeki veri nesnelerini bu nesnelerin kolayca yönetilebileceği ve tüketileceği şekilde göstermekten sorumludur. Bu bağlamda, Görünüm Modeli, Görünüm'den daha Modeldir ve Görünüm'ün tüm görüntüleme mantığı olmasa bile çoğunu işler.
MVVM, Görünüm katmanından hemen hemen tüm "arkada kodları" kaldırarak Görünüm katmanı gelişiminin modelin geri kalanından daha iyi ayrılmasını kolaylaştırmak için WPF'deki belirli işlevleri kullanmak üzere tasarlanmıştır. Etkileşimli Tasarımcıların Görünüm kodu yazmasını zorunlu tutmak yerine, yerel WPF biçimlendirme dili XAML'yi kullanabilir ve uygulama geliştiricileri tarafından yazılan ve sürdürülen ViewModel'e bağlamalar oluşturabilirler. Rollerin bu şekilde ayrılması, Etkileşimli Tasarımcıların programlama veya iş mantığı yerine UX ihtiyaçlarına odaklanmalarını sağlayarak, uygulama katmanlarının birden çok iş akışında geliştirilmesine olanak tanır.
Bu tür zengin etkileşimin gerekli olmadığı kullanıcı arayüzleri için MVVM aşırıya kaçabilir; MVP daha doğal bir seçim olabilir. Web uygulamaları için MVC daha uygundur. Asla daha büyük büyümeyecek çok küçük uygulamalar için (küçük Winforms yardımcı programları gibi), arkada kodlama yeterlidir.
Bazen MVVM bir tuzak olabilir. Deneyimlerime göre, CRUD benzeri uygulamaları (veriler üzerinde formlar) ve daha fazla görev odaklı kullanıcı arayüzlerini destekliyor. Ben uygulamada arka uç/diğerleri katmanlar için kötü mimarisi ima demiyorum ama ben "DDD ışık" mimarisi ile gelen çok MVVM uygulamaları gördük. Neden tam olarak bilmiyorum çünkü bağlama çok kolay ve POCO/Anemik etki alanı nesneleri kullanarak ORM ve MVVM/Ciltleme ile bir uygulama kurmak çok basit.
MVVM, kötü tasarlanmış veri bağlama katmanları için bir bant yardımcısıdır. Özellikle WPF/silverlight/WP7 dünyasında WPF/XAML'deki veri bağlamasındaki sınırlamalar nedeniyle çok fazla kullanım görmüştür.
Şu andan itibaren, WPF/XAML hakkında konuştuğumuzu varsayacağım, çünkü bu işleri daha net hale getirecek. MVVM'nin WPF/XAML'de çözmek için ortaya koyduğu bazı eksikliklere bakalım.
Veri şekli ve kullanıcı arayüzü şekli
MVVM'deki 'VM', CAM'de tanımlanan ve XAML'de tanımlanan bir sunum nesneleri kümesiyle eşlenen bir nesne kümesi oluşturur. Bu C # nesneleri genellikle XAML'ye sunum nesnelerindeki DataContext özellikleri aracılığıyla bağlanır.
Sonuç olarak, viewmodel nesne grafiğinin uygulamanızın sunu nesne grafiğine eşlenmesi gerekir. Bu, eşlemenin bire bir olması gerektiği anlamına gelmez, ancak bir liste denetimi bir pencere denetimi tarafından içeriyorsa, pencerenin DataContext nesnesinden o listenin verilerini açıklayan bir nesneye ulaşmanın bir yolu olmalıdır.
Viewmodel nesne grafiği, model nesne grafiğini ui nesne grafiğinden başarıyla ayırır, ancak oluşturulması ve bakımı gereken ek bir viewmodel katmanı pahasına.
Bazı verileri A ekranından B ekranına taşımak istersem, görünüm modelleri ile uğraşmak zorundayım. Bir iş adamının aklında, bu bir UI değişikliği. O tamamen XAML dünyasında gerçekleşmelidir . Ne yazık ki, nadiren olabilir. Daha da kötüsü, görünüm modellerinin nasıl yapılandırıldığına ve verilerin ne kadar aktif olarak değiştiğine bağlı olarak, bu değişikliği gerçekleştirmek için biraz veri yönlendirmesi gerekebilir.
Etkileyici veri bağlama etrafında çalışma
WPF/XAML bağlamaları yeterince etkileyici değildir. Temel olarak, bir nesneye ulaşmak için bir yol, geçiş için bir özellik yolu ve veri özelliğinin değerini sunum nesnesinin gerektirdiği şekilde uyarlamak için bağlayıcı dönüştürücüler sağlar.
C # 'daki bir özelliği bundan daha karmaşık bir şeye bağlamanız gerekiyorsa, temelde şansınız kalmaz. True/false'u Görünür/Daraltılmış hale getiren bir bağlayıcı dönüştürücü olmadan bir WPF uygulaması görmedim. Birçok WPF uygulaması, kutuplanmayı çevreleyen NegatingVisibilityConverter veya benzeri bir şeye sahip olma eğilimindedir. Bu alarm zillerinin kapalı olması gerekir.
MVVM, bu sınırlamayı düzeltmek için kullanılabilecek C # kodunuzu yapılandırmak için yönergeler verir. Görünüm modelinizde SomeButtonVisibility adlı bir özelliği açığa çıkarabilir ve bu düğmenin görünürlüğüne bağlayabilirsiniz. XAML'niz şimdi güzel ve güzel ... ama kendinizi bir katip haline getirdiniz - şimdi UI'niz geliştiğinde iki yerde (UI ve C # kodunda) bağlamaları açığa çıkarmanız gerekiyor. Başka bir ekranda bulunmak için aynı düğmeye ihtiyacınız varsa, bir görünüm modelinde benzer bir özelliği bu ekranın erişebileceği şekilde göstermeniz gerekir. Daha da kötüsü, sadece XAML'ye bakamıyorum ve düğmenin ne zaman görüneceğini göremiyorum. Bağlamalar biraz önemsiz olur olmaz, C # kodunda dedektiflik yapmak zorundayım.
Verilere erişim agresif bir şekilde kapsamlıdır
Veriler genellikle UI'ye DataContext özellikleri aracılığıyla girdiğinden, genel veya oturum verilerini uygulamanız boyunca tutarlı bir şekilde temsil etmek zordur.
"Şu anda oturum açmış kullanıcı" fikri harika bir örnektir - bu genellikle uygulamanızın bir örneğindeki gerçekten küresel bir şeydir. WPF/XAML'de mevcut kullanıcıya tutarlı bir şekilde küresel erişim sağlamak çok zordur.
Şu anda oturum açmış kullanıcıya başvurmak için veri bağlamaları Word "CurrentUser" serbestçe kullanmaktır. Bunun yerine, her DataContext geçerli kullanıcı nesnesine almak için bir yol verdiğinden emin olmak zorunda. MVVM bunu karşılayabilir, ancak hepsi bu küresel verilere erişim sağlamak zorunda olduğu için görünüm modelleri karışıklık yaratacaktır.
MVVM'nin devrildiği bir örnek
Diyelim ki bir kullanıcı listemiz var. Her kullanıcının yanında, yalnızca şu anda oturum açmış olan kullanıcının bir yönetici olması durumunda bir "kullanıcıyı sil" düğmesi görüntülemek istiyoruz. Ayrıca, kullanıcıların kendilerini silmelerine izin verilmez.
Model nesneleriniz şu anda oturum açmış olan kullanıcı hakkında bilgi sahibi olmamalıdır - sadece veritabanınızdaki kullanıcı kayıtlarını temsil ederler, ancak şu anda oturum açmış olan kullanıcının liste satırlarınızdaki veri bağlarına maruz kalması gerekir. MVVM, o anda oturum açmış olan kullanıcıyı o liste satırıyla temsil edilen kullanıcıyla birleştiren her liste satırı için bir viewmodel nesnesi oluşturmamızı ve ardından bu viewmodel nesnesinde (duygularınıza bağlı olarak "DeleteButtonVisibility" veya "CanDelete" adlı bir özelliği göstermemiz gerektiğini belirtir. bağlayıcı dönüştürücüler hakkında).
Bu nesne, diğer birçok şekilde bir User nesnesi gibi korkunç bir lot gibi görünecektir - kullanıcı modeli nesnesinin tüm özelliklerini yansıtması ve değiştikçe bu verilere güncellemeleri iletmesi gerekebilir. Bu gerçekten çok gergin geliyor - MVVM, bu kullanıcı-benzeri nesneyi sürdürmeye zorlayarak sizi bir katip yapar.
Düşünün - muhtemelen bir veritabanı, model ve görünümde kullanıcı özelliklerini temsil etmek zorundasınız. Siz ve veritabanınız arasında bir API'niz varsa, daha da kötüsü - veritabanında, API sunucusunda, API istemcisinde, modelde ve görünümde temsil edilirler. Her özellik eklendiğinde veya değiştiğinde dokunulması gereken başka bir katman ekleyen bir tasarım deseni benimsemekten gerçekten çekinirim.
Daha da kötüsü, bu katman veri modelinizin karmaşıklığıyla değil, kullanıcı arayüzünüzün karmaşıklığıyla ölçeklenir. Genellikle aynı veriler birçok yerde ve kullanıcı arayüzünüzde temsil edilir - bu sadece bir katman eklemekle kalmaz, çok fazla ekstra yüzey alanına sahip katman ekler!
İşler nasıl olabilirdi
Yukarıda açıklanan durumda şunu söylemek istiyorum:
<Button Visibility="{CurrentUser.IsAdmin && CurrentUser.Id != Id}" ... />
CurrentUser, uygulamamdaki tüm XAML'ye global olarak maruz kalacaktı. Kimlik, liste satırım için DataContext üzerinde bir özelliğe başvuruyor. Görünürlük otomatik olarak boole'den dönüştürülür. Id, CurrentUser.IsAdmin, CurrentUser veya CurrentUser.Id güncelleştirmeleri bu düğmenin görünürlüğüne yönelik bir güncellemeyi tetikler. Çantada keklik.
Bunun yerine, WPF/XAML kullanıcılarını tam bir karmaşa yaratmaya zorlar. Anlayabildiğim kadarıyla, bazı yaratıcı blogcular bu karışıklığa bir isim verdiler ve bu isim MVVM idi. Aldanmayın - GoF tasarım desenleriyle aynı sınıfta değildir. Bu çirkin bir veri bağlama sistemi üzerinde çalışmak için çirkin bir kesmek.
(Bu yaklaşıma bazen daha fazla okuma yapmanız durumunda "Fonksiyonel Reaktif Programlama" da denir).
Sonuç olarak
WPF/XAML'de çalışmanız gerekiyorsa, hala MVVM'yi önermiyorum.
Kodunuzun, yukarıdaki "işlerin nasıl olabileceği" örneğinin, karmaşık veri bağlama ifadeleri + esnek değer zorlamaları ile doğrudan görünüme maruz kalması gibi yapılandırılmasını istiyorsunuz. Çok daha iyi - daha kolay okunabilir, daha yazılabilir ve daha kolay bakım.
MVVM, kodunuzu daha ayrıntılı, daha az bakım yapılabilir bir şekilde yapılandırmanızı söyler.
MVVM yerine, iyi deneyime yaklaşmanıza yardımcı olacak bazı şeyler oluşturun: Küresel durumu kullanıcı arayüzünüze tutarlı bir şekilde tanıtmak için bir kural geliştirin. Daha karmaşık ciltleme ifadeleri ifade etmenizi sağlayan ciltleme dönüştürücüler, MultiBinding, vb. Kendinizi, ortak zorlama vakalarını daha az ağrılı hale getirmeye yardımcı olacak bir bağlayıcı dönüştürücüler kütüphanesi oluşturun.
Daha da iyisi - XAML'i daha etkileyici bir şeyle değiştirin. XAML, C # nesnelerini örneklemek için çok basit bir XML biçimidir - daha etkileyici bir varyant bulmak zor olmaz.
Diğer tavsiyem: bu tür tavizleri zorlayan araç takımları kullanmayın. Sizi sorun alanınıza odaklanmak yerine MVVM gibi saçmalıklara doğru iterek son ürününüzün kalitesine zarar verecektir.
MVVM'yi gerçekten çok seviyorum ve zorluklarını motive ediyor ve birçok faydası görüyorum, ama ...
Mükemmelliği korurken çok fazla özel davranış eklemek için çok fazla UI/etkileşim kodu gerektiren uygulama veya oyunlar için - genellikle biraz kirli MVVM kullanmak daha iyidir - yararlı olduğunda veya aksine daha fazla veri merkezli olduğunda kullanın etkileşim merkezi kod alanları. Bir denetim oluşturmak ve farklı üst denetimler arasında taşımak veya başka bir şekilde önbelleğe almak istediğinizi varsayalım ...
Oldukça dik bir öğrenme eğrisi vardır, bu yüzden zamanınız yoksa, WPF/SL'de çok şey geliştirmeyi planlayın, Blend konusunda yetenekli tasarımcılara sahip olun, kullanıcı arayüzünüz için test kodu yazma gereğini hissedin veya aksi takdirde sizin için yıllarca bakım yapmayı bekleyebilirsiniz. proje - işe yaramayabilir.
Pek çok tasarımcı Blend'i bilmiyor, tüm projeler otomatik testin sunum katmanına odaklanmasına değmiyor, çünkü yine de manuel olarak test edilmesi gerekiyor ve VM'lerinizi test ederek değil, en önemli hataları bu şekilde bulacaksınız.
Gerçekten bir yatırım. Önce WPF/SL ve XAML temellerini kavramanız, ardından bağlamaları doğru yapmanın yollarını bulmanız, vms'a vs bir şekilde bağlamanız, komutunuzu doğru almanız, çoğu durumda bir çerçeve seçmeniz gerekir. lisanslama nedeniyle sorunlu olun, verimli bir şekilde kodlamak için bir sippets kütüphanesi oluşturun, sadece platformun her zaman bağlarla iyi çalışmadığını ve ihtiyacınız olanı elde eden bir davranış kütüphanesi oluşturmaya ihtiyaç duyduğunu bulun.
Genel olarak - eğer tüm engelleri aşarsanız ve desende oldukça proffent olursanız - hepsi netlik, sürdürülebilirlik ve ... Övünme hakları olarak geri ödenir mi? :)
MVVM'de ticaret sistemleri gibi devasa uygulamalar geliştiren yıllardır WPF/Silverlight programcısıyım.
Benim için yıllar geçtikçe katı MVVM'nin zaman aldığını ve paraya mal olduğunu öğrendim. Kesinlikle, "arkasında kod yok" gibi kuralları kastediyorum.
En temel form/veritabanı uygulamasından başka bir şey imkansızdır, kod arkasına sahip olmak değil.
Tasarımcınız ilk gün standart kontrollerle mümkün olmayan bir şey belirleyecektir, bu nedenle MVVM ile çalışırken etkileşim paradigmasını desteklemek için bir dizi özel kontrol oluşturmalı veya mevcut kontrolleri sarmalısınız.
Matematik, atalet, jestler vb. Kullanarak her türlü swish UI kontrolünü yazdım.
Ama bunların hepsi arka planda, sadece görünümde değil. Düğme tıklamaları, kaydırma, sürükleme vb. İşlemek zorundasınız, ancak hepsi güzel bir şekilde bir dizi denetime sarılmış, bu da bir şekilde bu kodu geride bırakıyor.
Sadece kodun arkasındaki ve akıllı UI öğelerini sadece bunun uğruna bir dizi kontrol oluşturmak yerine, görünümde yazmak genellikle daha kolaydır.
MVVM'nin amacı, uygulama/iş mantığını UI mantığından ayırmaktır. Bağlama sistemi ve MVVM bunu yapmanın güzel bir yoludur.
Bir masada XAML tasarımcısı, diğerinde C # programcısı, diğeri VS'de Karıştır'da çalışan diğer hedefler yanlıştır.
Bir kullanıcı arayüzünü hızlı bir şekilde yeniden tasarlayabilmek başka bir yanlıştır. Asla gerçekleşmez, erken optimizasyonu; herhangi bir büyük yeniden işleme, görünüm modellerine çok fazla çalışma gerektirir. Tweaking bir şeydir, ancak hızlı UI revizyonları mümkün değildir; görünüm modelleri etkileşim paradigmasına uymalıdır, bu nedenle bağlantı fark edebileceğinizden daha sıkıdır.
Benim için, uygulama mantığımı ayrı tutmak için MVVM kullanıyorum (genellikle test edilebilir bir kontrolör ve bir dizi mantıksız görünüm modeli kullanıyorum), ancak arayüzümün seksi bir şekilde görünmesi ve davranması için gerekli kod ve püf noktaları ne olursa olsun, terlemek.
Yoksa sadece MVVM-arize nasıl fikri çok akıllara durgun hale gelir çünkü tasarımlar, serin animasyonlar, vb hükümdarlık sonunda.
MVVM, hayattaki çoğu şey gibi, bir yerde tatlı bir noktaya sahiptir arasında iki uç.
Yazılım tasarımındaki en önemli şey, ürününüzü erken göndermek, hangi özelliklerin kullanıldığını, hangi arayüzün iyi çalıştığını bulmak ve kimsenin kullanmadığı bir ürün için güzel kod yazmamaktır.
Uygulamanız gerçek zamanlı olarak aşırı miktarda veriye bağlanmanızı gerektiriyorsa, MVVM aslında yol alabilir, çünkü süreci yavaşlatan soyutlamalar getiriyor ve şu anda WPF/Silverlight/WP7 hakkında konuştuğumuzu varsayarak, motor şu anda bu kadar verimli değil; geliştirmeler yolda olmasına rağmen.
MVVM, durduğu gibi, denklemin dikkate almanız gereken tek kısmı değildir. Bağlantısı kesilmiş ViewModels üzerinden iletişim kurmanıza olanak sağlamak için Pure MVVM'nin Arabulucu deseni gibi altyapı ile desteklenmesi gerekir.
Yukarıdaki blucz görüşüne rağmen, MVVM GoF modelleri doğrultusundadır. Desenlere bakarsanız, MVVM, yaklaşık olarak MVVM ile aynı anda görünen Model Görünümü Pasif Presenter deseninin eşdeğeridir. Burada sık sık insanlar MVVM'nin karmaşıklığından tamamen şikayet edeceklerdir, çünkü onu kullanarak nasıl tasarlanacağını anlamıyorlar.
MVVM ile ilgili sorunlar bulduğum bir başka alan da, onu desteklemek için tasarlanmamış bir üçüncü taraf teknolojisini (MS Dynamics UII çerçevesi gibi) dahil etmeniz gereken yerdir. Bazen kendinize sadece MVVM ile çalışmak için diğer teknolojinin etrafında "hackleme" acısına değip değmeyeceğini sormanız gerekir.
Win Forms gibi bir şeyi WPF çözümünüzle karıştırıp eşleştiriyorsanız, çözümün bu kısmı muhtemelen MVVM için uygun olmayacaktır. Umarım bu MVVM'nin geçerli olmadığı bazı alanlar hakkında size fikir verir.
MVVM kullanmak şu durumlarda mantıklı değildir:
Bu kadar. Ayrı bir projede bir şeyi test etmeden veya hata ayıklamadığınız sürece, WPF/Silverlight ile çalışırken neden MVVM'yi kullanmayacağınızı gerçekten düşünemiyorum. XAML Ciltlerinin çalışma şekli nedeniyle tasarım desenini WPF/Silverlight gelişimi için ideal buluyorum.
MVVM'nin asıl amacı, tüm uygulamanızın ViewModels'inizde çalıştırılması ve Görünümlerinizin, kullanıcıların ViewModels'ınızla etkileşim kurmak için kullanabileceği güzel bir katman olmasıdır. Bir düğmeyi tıklatmak istiyorsunuz, aslında bir ViewModel yöntemi çalıştırıyorsunuz. Sayfayı değiştirmek istiyorsunuz, aslında ViewModel'de CurrentPage özelliğini değiştiriyorsunuz.
MVVM'yi tüm WPF/Silverlight geliştirme, hatta küçük, basit tek sayfalı projeler için kullanıyorum, ancak MVVM'yi nasıl kullanacağım projenin boyutuna ve neye ihtiyacım olduğuna bağlı olarak farklı. Bir kez MVVM olmadan küçük bir uygulama yaptım, pişman oldum (daha sonra bir güncelleme eklerken MVVM kullanmak için refactored var)
MVVM dönüştürmek için bir girişim ile kod arkasında bir projede bir istemci için biraz iş yaptım ve dev bir karışıklık oldu. Bu, kod arkasındaki tüm projelerin bir karışıklık olduğu anlamına gelmez. Görünümler hata veya tasarımcılar için sorunlara neden olan Blend çökmesine.
RoR ile dabbled ve hemen hemen ASP.NET Webforms ile bir şey yapmayı atladım ama ASP.NET MVC çıktı zaman ben mümkün olduğunca öğrenmeye çalıştım, sık sık ASP.NET MVC In Action kitap ve codecampserver referans olarak kullanarak . Farklı bir desen olmasına rağmen SL/MVVM geliştirmede In Action kitaplarından öğrendiğim şeylerin çoğunu kullanıyorum.
Silverlight ile çalışmaya başladığımda ne kadar çıplak olduğuna şaşırdım ve giyinmek için mevcut birçok çerçeveden birini seçmek bir gereklilik gibi hissettim. Bunu MVVM öğrenmekten vazgeçen insanlarla ilgili bir sorun olarak görüyorum.
Desenin satılan bir kavrayışını elde etmeme yardımcı olan mükemmel MVVM-Light ile başladım. Daha sonra Caliburn Micro ile çalışmaya başladım ve ışıklar yanmaya başladı. Bana göre Caliburn Micro , ASP.NET Web formları üzerinden ASP.NET MVC kullanmak gibidir. Bu nedenle, küçük örnek uygulamalar için bile NuGet CM projesini oluşturuyorum ve çalışıyorum. ViewModel ilk yaklaşımını izler ve Görünümlerimi aptal ve kolay bir şekilde Blend'de tutarım. VM'lerim bunun içindeyseniz test edilebilir ve CM ile karmaşık ekran düzenlerini dolaşmak oldukça kolaydır.
Bu alternatifi incelemekten keyif alabilirsiniz. Bu seçenek, veri aktarma, veri şablonları ve MVVM'nin WPF yolunu kaldırır. Bu seçenek daha çok eski, basit, güvenilir WinForms designer.cs yaklaşımına benzer.
WPF Kompozitleri
Burada, WPF için özlü C # kod arkası, ızgara tabanlı kompozitler aracılığıyla UI'nin üzerine basit bir matrisin üst üste binmesiyle üretilir. Modern bir XAML kullanıcı arayüzü yalnızca birkaç metin etiketi ve bir liste kutusu içeriyorsa, bu neden basit bir kod satırı ile tanımlanamıyor: grid.AddText (guid, x koordinatı, y koordinatı)? Bunun bir tuval üzerinde değil, yine de WPF kaplarının içinde olduğunu unutmayın: ızgara, dockpanel, vb. WPF çok güçlüdür. Bu yaklaşım sadece bundan yararlanır.
Geliştiriciler genellikle matrisleri ve indeksleri dikkate almazlar. Veri aktarım nesnelerinin (DTO'lar) veya POCO'ların GUID'leri tarafından tanımlanan kaba taneli bir kapsayıcı düzeyi ile başlayın, daha sonra bu anahtarlı kapları içerisindeki potansiyel satır ve sütunların daha ince taneli bir matrisiyle tamamlayın.
Yukarıdaki codeplex projesi, ListBox denetimi ile başlayarak bu yaklaşımı sunar, ancak tüm WPF kompozit denetimlerini kapsayacak şekilde genişler. Örneğin, her liste kutusu öğesi bir GUID (bir bileşik bir ile bir sınıfı sınıfa bağlar) ile eklenen bir bileşiktir, daha sonra bu öğenin içinde alt UI öğelerinin ( çocuklar bir sınıftaki özelliklere birebir bağlar), kod arkası yoluyla istek üzerine eklenebilir.Çocuklar metin bloğu veya görüntü olabilir.
Fikir, veri şablonları yerine indekslerden ve iyi tanımlanmış bir UI Element yapısından (temel olarak bir PresentationFramework.Aero temalı ListBox'ı başlamak için zorlar) kullanmaktır. Bu yeni yaklaşım kasıtlı olarak yapılabilecekleri sınırlar ancak bunu yaparak sezgisel olan özlü, sağlam C # kod arkası sağlar. Kaydırma çubuğunu şekillendirmek için kontrol şablonu çözümlerini aramaya veya basit görevler için birden çok veri şablonuyla bir çözümü dağıtmaya gerek yoktur.