WPF'de MVVM - Modeldeki değişiklikler için ViewModel nasıl uyarılır… yoksa yapmalı mıyım?

Başta bu ve bu olmak üzere bazı MVVM makalelerinden geçiyorum .

Benim özel sorum şudur: Model değişikliklerini Modelden ViewModel'e nasıl iletebilirim?

Josh'un makalesinde, bunu yaptığını görmüyorum. ViewModel her zaman Modelden özellikler ister. Rachel'ın örneğinde, model uygulamasına sahip ve modeldeki INotifyPropertyChangedolayları yükseltiyor, ancak bunlar görünümün kendisi tarafından tüketim içindir (bunu neden yaptığına dair daha fazla ayrıntı için makalesine / koduna bakın).

Modelin ViewModel'i model özelliklerinde yapılan değişiklikler konusunda uyardığı örnekleri hiçbir yerde görmüyorum. Bu beni, belki de bir nedenden dolayı yapılmadığı konusunda endişelendiriyor. Modeldeki değişiklikler için ViewModel'i uyarmak için bir model var mı? (1) Muhtemelen her model için 1'den fazla ViewModel olduğundan ve (2) sadece bir ViewModel olsa bile, model üzerindeki bazı eylemler diğer özelliklerin değişmesine neden olabilir.

"Bunu neden yapmak istersiniz?" Şeklinde cevaplar / yorumlar olabileceğinden şüpheleniyorum. yorumlar, işte programımın bir açıklaması. MVVM'de yeniyim, bu yüzden belki de tüm tasarımım hatalı. Kısaca anlatacağım.

"Müşteri" veya "Ürün" sınıflarından daha ilginç (en azından benim için!) Bir şey programlıyorum. BlackJack'i programlıyorum.

Arkasında herhangi bir kod bulunmayan ve sadece ViewModel'deki özelliklere ve komutlara bağlanmaya dayanan bir View'um var (Josh Smith'in makalesine bakın).

İyi ya da kötü, ben Modeli gibi sadece sınıfları yer almasına da tavır aldı PlayingCard, Deckfakat aynı zamanda BlackJackGamebütün oyunun durumunu tutan sınıfını ve oyuncu gitti büstü sahip olduğunda, satıcı kart çekmek zorundadır bilir ve Oyuncu ve krupiyenin şu anki skoru (21, 21'den az, bust, vb.).

Gönderen BlackJackGameben "drawcard" gibi yöntemleri göstermek ve onu aklıma bir kart gibi özelliklere çizildiğinde CardScoreve IsBustgüncellenmesi gerekir ve bu yeni değerler ViewModel tebliğ. Belki de yanlış düşünme budur?

Kişi, ViewModel'in DrawCard()yöntemi çağırdığı tavrı benimseyebilir, böylece güncellenmiş bir puan istemeyi bilmesi ve iflas edip etmediğini öğrenmesi gerekir. Görüşler?

ViewModel'imde, bir oyun kartının gerçek bir görüntüsünü (renk, rütbeye göre) alma ve görünüm için kullanılabilir hale getirme mantığına sahibim. Model bununla ilgilenmemelidir (belki başka ViewModel, kart görüntülerini oynamak yerine sadece sayıları kullanır). Elbette, belki bazıları bana Modelin bir BlackJack oyunu konseptine sahip olmaması gerektiğini ve bunun ViewModel'de ele alınması gerektiğini söyler?

Modellerinizin ViewModels değişikliklerini uyarmasını istiyorsanız, INotifyPropertyChanged uygulamasını uygulamalı ve ViewModels PropertyChange bildirimlerini almak için abone olmalıdır.

Kodunuz aşağıdaki gibi görünebilir:

// Attach EventHandler
PlayerModel.PropertyChanged += PlayerModel_PropertyChanged;

...

// When property gets changed in the Model, raise the PropertyChanged 
// event of the ViewModel copy of the property
PlayerModel_PropertyChanged(object sender, PropertyChangedEventArgs e)
{
    if (e.PropertyName == "SomeProperty")
        RaisePropertyChanged("ViewModelCopyOfSomeProperty");
}

Ancak genellikle bu, yalnızca birden fazla nesne Model verilerinde değişiklik yapacaksa gereklidir, bu genellikle böyle değildir.

PropertyChanged olayını ona iliştirmek için Model mülkünüze aslında bir referansınız olmadığı bir durumunuz varsa, Prism's EventAggregatorveya MVVM Light's gibi bir Mesajlaşma sistemi kullanabilirsiniz Messenger.

Blogumda mesajlaşma sistemlerine kısa bir genel bakış var , ancak bunu özetlemek gerekirse, herhangi bir nesne bir mesaj yayınlayabilir ve herhangi bir nesne belirli mesajları dinlemek için abone olabilir. Böylece PlayerScoreHasChangedMessagebir nesneden bir yayın yayınlayabilirsiniz ve başka bir nesne bu tür mesajları dinlemek için abone olabilir ve PlayerScorebirini duyduğunda özelliğini güncelleyebilir .

Ama tarif ettiğiniz sistem için bunun gerekli olduğunu düşünmüyorum.

İdeal bir MVVM dünyasında, uygulamanız ViewModel'lerinizden oluşur ve Modelleriniz, uygulamanızı oluşturmak için kullanılan bloklardır. Tipik olarak yalnızca veri içerirler, bu nedenle DrawCard()(bir ViewModel'de olacak) gibi yöntemlere sahip olmazlardı.

Yani muhtemelen aşağıdakiler gibi düz Model veri nesnelerine sahip olursunuz:

class CardModel
{
    int Score;
    SuitEnum Suit;
    CardEnum CardValue;
}

class PlayerModel 
{
    ObservableCollection<Card> FaceUpCards;
    ObservableCollection<Card> FaceDownCards;
    int CurrentScore;

    bool IsBust
    {
        get
        {
            return Score > 21;
        }
    }
}

ve aşağıdaki gibi bir ViewModel nesneniz olur

public class GameViewModel
{
    ObservableCollection<CardModel> Deck;
    PlayerModel Dealer;
    PlayerModel Player;

    ICommand DrawCardCommand;

    void DrawCard(Player currentPlayer)
    {
        var nextCard = Deck.First();
        currentPlayer.FaceUpCards.Add(nextCard);

        if (currentPlayer.IsBust)
            // Process next player turn

        Deck.Remove(nextCard);
    }
}

(Yukarıdaki nesnelerin tümü uygulanmalıdır INotifyPropertyChanged, ancak basit olması için onu dışarıda bıraktım)

Kısa cevap: ayrıntılara bağlıdır.

Örneğinizde modeller "kendi başlarına" güncelleniyor ve bu değişikliklerin elbette bir şekilde görüşlere yayılması gerekiyor. Görünümler yalnızca doğrudan görünüm modellerine erişebildiğinden, modelin bu değişiklikleri ilgili görünüm modeline iletmesi gerektiği anlamına gelir. Bunu yapmak için yerleşik mekanizma elbette şudur INotifyPropertyChanged, bu da aşağıdaki gibi bir iş akışı alacağınız anlamına gelir:

1. Viewmodel oluşturulur ve modeli sarar
2. Viewmodel, modelin PropertyChangedetkinliğine abone olur
3. Viewmodel, görünümler olarak ayarlanır DataContext, özellikler bağlıdır vb.
4. Viewmodel'de tetikleyici eylemini görüntüleyin
5. Viewmodel, model üzerinde yöntemi çağırır
6. Model kendini günceller
7. Viewmodel, modeli işler PropertyChangedve PropertyChangedyanıt olarak kendi modelini yükseltir
8. Görünüm, geri bildirim döngüsünü kapatarak bağlamalarındaki değişiklikleri yansıtır

Öte yandan, modelleriniz çok az iş mantığı içeriyorsa (veya hiç yoksa) veya başka bir nedenle (işlem yeteneği kazanmak gibi) her bir görünüm modelinin kendi sarmalanmış modeline "sahip olmasına" izin verdiyseniz, modelde yapılan tüm değişiklikler geçecektir. görünüm modeli, böylece böyle bir düzenleme gerekli olmayacaktır.

Başka bir MVVM söz konusu böyle bir tasarım tarif burada .

Senin seçimlerin:

• INotifyPropertyChanged uygula
• Etkinlikler
• Proxy manipülatörlü POCO

Gördüğüm kadarıyla INotifyPropertyChanged.Net'in temel bir parçası. yani içinde System.dll. Bunu "Modelinize" uygulamak, bir olay yapısını uygulamaya benzer.

Saf POCO istiyorsanız, nesnelerinizi proxy'ler / hizmetler aracılığıyla etkili bir şekilde değiştirmeniz gerekir ve ardından ViewModel'iniz, proxy'yi dinleyerek değişikliklerden haberdar edilir.

Şahsen ben INotifyPropertyChanged'i gevşek bir şekilde uyguluyorum ve sonra kirli işi benim için yapmak için FODY kullanıyorum . POCO'ya bakıyor ve hissediyor.

Bir örnek (FODY'den IL'ye PropertyChanged yükselticileri dokumayı kullanarak):

public class NearlyPOCO: INotifyPropertyChanged
{
     public string ValueA {get;set;}
     public string ValueB {get;set;}

     public event PropertyChangedEventHandler PropertyChanged;
}

sonra ViewModel'inizin herhangi bir değişiklik için PropertyChanged'ı dinlemesini sağlayabilirsiniz; veya mülke özgü değişiklikler.

INotifyPropertyChanged rotasının güzelliği, onu Extended ObservableCollection ile zincirlemenizdir . Böylece, yakın poco nesnelerinizi bir koleksiyona atarsınız ve koleksiyonu dinlersiniz ... herhangi bir değişiklik olursa, herhangi bir yerde, onu öğrenirsiniz.

Dürüst olacağım, bu "Neden derleyici tarafından otomatik olarak INotifyPropertyChanged yapılmadı" tartışmasına katılabilir, bu tartışmada şu konulara ayrılır: c # içindeki her nesnenin herhangi bir parçası değiştirildiğinde bildirimde bulunma olanağı olmalıdır; yani INotifyPropertyChanged'i varsayılan olarak uygulayın. Ama öyle değil ve en az çaba gerektiren en iyi yol IL Weaving'i (özellikle FODY ) kullanmaktır.

Oldukça eski bir iş parçacığı, ancak çok fazla araştırmadan sonra kendi çözümümü buldum: Bir Özellik Değiştirilmiş Proxy

Bu sınıfla, başka birinin NotifyPropertyChanged programına kolayca kaydolabilir ve kayıtlı mülk için çalıştırılırsa uygun önlemleri alabilirsiniz.

Aşağıda, kendi başına değişebilen bir model özelliği olan "Durum" a sahip olduğunuzda bunun nasıl görünebileceğine dair bir örnek verilmiştir ve ardından ViewModel'e kendi PropertyChanged özelliğini kendi PropertyChanged özelliğini çalıştırması için otomatik olarak bildirmesi gerekir, böylece görünüm de bildirilir: )

public class MyModel : INotifyPropertyChanged
{
    private string _status;
    public string Status
    {
        get { return _status; }
        set { _status = value; OnPropertyChanged(); }
    }

    // Default INotifyPropertyChanged
    public event PropertyChangedEventHandler PropertyChanged;
    protected virtual void OnPropertyChanged([CallerMemberName] string propertyName = null)
    {
        var handler = PropertyChanged;
        if (handler != null) handler(this, new PropertyChangedEventArgs(propertyName));
    }
}

public class MyViewModel : INotifyPropertyChanged
{
    public string Status
    {
        get { return _model.Status; }
    }

    private PropertyChangedProxy<MyModel, string> _statusPropertyChangedProxy;
    private MyModel _model;
    public MyViewModel(MyModel model)
    {
        _model = model;
        _statusPropertyChangedProxy = new PropertyChangedProxy<MyModel, string>(
            _model, myModel => myModel.Status, s => OnPropertyChanged("Status")
        );
    }

    // Default INotifyPropertyChanged
    public event PropertyChangedEventHandler PropertyChanged;
    protected virtual void OnPropertyChanged([CallerMemberName] string propertyName = null)
    {
        var handler = PropertyChanged;
        if (handler != null) handler(this, new PropertyChangedEventArgs(propertyName));
    }
}

ve işte sınıfın kendisi:

/// <summary>
/// Proxy class to easily take actions when a specific property in the "source" changed
/// </summary>
/// Last updated: 20.01.2015
/// <typeparam name="TSource">Type of the source</typeparam>
/// <typeparam name="TPropType">Type of the property</typeparam>
public class PropertyChangedProxy<TSource, TPropType> where TSource : INotifyPropertyChanged
{
    private readonly Func<TSource, TPropType> _getValueFunc;
    private readonly TSource _source;
    private readonly Action<TPropType> _onPropertyChanged;
    private readonly string _modelPropertyname;

    /// <summary>
    /// Constructor for a property changed proxy
    /// </summary>
    /// <param name="source">The source object to listen for property changes</param>
    /// <param name="selectorExpression">Expression to the property of the source</param>
    /// <param name="onPropertyChanged">Action to take when a property changed was fired</param>
    public PropertyChangedProxy(TSource source, Expression<Func<TSource, TPropType>> selectorExpression, Action<TPropType> onPropertyChanged)
    {
        _source = source;
        _onPropertyChanged = onPropertyChanged;
        // Property "getter" to get the value
        _getValueFunc = selectorExpression.Compile();
        // Name of the property
        var body = (MemberExpression)selectorExpression.Body;
        _modelPropertyname = body.Member.Name;
        // Changed event
        _source.PropertyChanged += SourcePropertyChanged;
    }

    private void SourcePropertyChanged(object sender, PropertyChangedEventArgs e)
    {
        if (e.PropertyName == _modelPropertyname)
        {
            _onPropertyChanged(_getValueFunc(_source));
        }
    }
}

Bu makaleyi yararlı buldum: http://social.msdn.microsoft.com/Forums/vstudio/en-US/3eb70678-c216-414f-a4a5-e1e3e557bb95/mvvm-businesslogic-is-part-of-the-?forum = wPF

Özetim:

MVVM organizasyonunun arkasındaki fikir, görünümlerin ve modellerin daha kolay yeniden kullanımına izin vermek ve ayrıca ayrıştırılmış testlere izin vermektir. Görünüm modeliniz, görünüm varlıklarını temsil eden bir modeldir, modeliniz işletme varlıklarını temsil eder.

Ya daha sonra bir poker oyunu yapmak istersen? Kullanıcı arayüzünün çoğu yeniden kullanılabilir olmalıdır. Oyun mantığınız görünüm modelinize bağlıysa, bu öğeleri görünüm modelini yeniden programlamak zorunda kalmadan yeniden kullanmak çok zor olacaktır. Kullanıcı arayüzünüzü değiştirmek isterseniz ne olur? Oyun mantığınız görünüm modeli mantığınıza bağlıysa, oyununuzun hala çalışıp çalışmadığını tekrar kontrol etmeniz gerekir. Ya bir masaüstü ve bir web uygulaması oluşturmak istiyorsanız? Görünüm modeliniz oyun mantığını içeriyorsa, uygulama mantığı kaçınılmaz olarak görünüm modelindeki iş mantığına bağlı olacağından, bu iki uygulamayı yan yana sürdürmeye çalışmak karmaşık hale gelir.

Veri değişikliği bildirimleri ve veri doğrulama her katmanda (görünüm, görünüm modeli ve model) gerçekleşir.

Model, veri temsillerinizi (varlıkları) ve bu varlıklara özgü iş mantığını içerir. Bir kart destesi, doğasında bulunan özelliklere sahip mantıksal bir 'şey'dir. İyi bir desteye çift kartlar yerleştirilemez. En iyi kart (lar) ı almanın bir yolunu göstermesi gerekiyor. Kalandan daha fazla kart vermemesi gerektiğini bilmesi gerekiyor. Bu tür deste davranışları, bir deste kartın doğasında olduğundan modelin bir parçasıdır. Ayrıca bayi modelleri, oyuncu modelleri, el modelleri vb. Olacaktır. Bu modeller etkileşim kurabilir ve etkileşimde bulunacaktır.

Görünüm modeli, sunum ve uygulama mantığından oluşacaktır. Oyunu sergilemeyle ilgili tüm çalışmalar oyunun mantığından ayrıdır. Bu, ellerin resim olarak gösterilmesini, bayi modeline kart taleplerini, kullanıcı görüntüleme ayarlarını vb. İçerebilir.

Makalenin cesareti:

Temel olarak, bunu açıklamayı sevdiğim yol, iş mantığınızın ve varlıklarınızın modeli oluşturmasıdır. Bu, özel uygulamanızın kullandığı şeydir, ancak birçok uygulama arasında paylaşılabilir.

Görünüm, sunum katmanıdır - aslında doğrudan kullanıcıyla arayüz oluşturmayla ilgili her şey.

ViewModel, temelde ikisini birbirine bağlayan uygulamanıza özgü "yapıştırıcıdır".

Burada nasıl arayüz oluşturduklarını gösteren güzel bir diyagramım var:

http://reedcopsey.com/2010/01/06/better-user-and-developer-experiences-from-windows-forms-to-wpf-with-mvvm-part-7-mvvm/

Sizin durumunuzda - bazı özellikleri ele alalım ...

Doğrulama: Bu genellikle 2 şekilde gelir. Kullanıcı girdisiyle ilgili doğrulama, ViewModel'de (öncelikle) ve Görünümde (yani: metnin girilmesini önleyen "Sayısal" Metin Kutusu, görünümde sizin için işlenir, vb.) Gerçekleşir. Bu nedenle, kullanıcıdan gelen girdinin doğrulanması tipik olarak bir VM sorunudur. Bununla birlikte, genellikle ikinci bir doğrulama "katmanı" vardır - bu, kullanılan verilerin iş kurallarıyla eşleştiğinin doğrulanmasıdır. Bu genellikle modelin bir parçasıdır - verileri Modelinize aktardığınızda, doğrulama hatalarına neden olabilir. VM daha sonra bu bilgiyi Görünüme geri göndermelidir.

DB'ye yazma, e-posta gönderme vb. Gibi "perde arkasındaki sahne arkası işlemler": Bu, diyagramımdaki "Etki Alanına Özgü İşlemler" in gerçekten bir parçasıdır ve gerçekten tamamen Modelin bir parçasıdır. Uygulama aracılığıyla ifşa etmeye çalıştığınız şey budur. ViewModel, bu bilgileri açığa çıkarmak için bir köprü görevi görür, ancak işlemler saf Modeldir.

ViewModel için İşlemler: ViewModel, INPC'den daha fazlasına ihtiyaç duyar - ayrıca, kaydetme tercihleri ​​ve kullanıcı durumu vb. Gibi uygulamanıza özgü (iş mantığınıza değil) herhangi bir işleme de ihtiyaç duyar. Bu, uygulamayı değiştirecektir. uygulamaya göre, aynı "model" ile arayüz oluştururken bile.

Bunu düşünmenin iyi bir yolu - Sipariş sisteminizin 2 versiyonunu yapmak istediğinizi varsayalım. Birincisi WPF'de, ikincisi ise bir web arayüzü.

Siparişlerin kendisiyle ilgilenen paylaşılan mantık (e-posta gönderme, DB'ye girme vb.) Modeldir. Uygulamanız bu işlemleri ve verileri kullanıcıya ifşa ediyor, ancak bunu 2 şekilde yapıyor.

WPF uygulamasında, kullanıcı arabirimi (görüntüleyicinin etkileşime girdiği) "görünüm" dür - web uygulamasında, bu temelde (en azından sonunda) istemcide javascript + html + css'ye dönüştürülen koddur.

ViewModel, modelinizin kullandığınız belirli görünüm teknolojisi / katmanıyla çalışmasını sağlamak için modelinizi (siparişle ilgili bu işlemler) uyarlamak için gereken "tutkal" ın geri kalan kısmıdır.

INotifyPropertyChanged ve INotifyCollectionChanged tabanlı bildirim tam olarak ihtiyacınız olan şeydir. Bellek sızıntılarını önleme, mülkiyet değişiklikleri, mülkiyet adının derleme zamanı doğrulama aboneliğine hayatınızı kolaylaştırmak için, sana kullanmayı tavsiye ediyorum PropertyObserver gelen Josh Smith'in MVVM Vakfı . Bu proje açık kaynak olduğundan, kaynaklardan projenize sadece o sınıfı ekleyebilirsiniz.

PropertyObserver'ın nasıl kullanılacağını anlamak için bu makaleyi okuyun .

Ayrıca, Reaktif Uzantılara (Rx) daha derin bir göz atın . Modelinizden IObserver <T> açığa çıkarabilir ve görünüm modelinde ona abone olabilirsiniz.

Adamlar bunu yanıtlamak için harika bir iş çıkardılar ama böyle durumlarda MVVM modelinin gerçekten bir acı olduğunu hissediyorum, bu yüzden gidip bir Denetleyici Denetleyici veya Pasif Görüş yaklaşımı kullanacak ve en azından model nesneler için bağlama sistemini bırakacaktım. kendi başlarına değişiklikler üretir.

Yönlü Modeli -> Modeli Görüntüle -> Değişikliklerin akışını uzun süredir savunuyorum, 2008'deki MVVM makalemin Değişiklik Akışı bölümünde . Bu INotifyPropertyChanged, model üzerinde uygulamayı gerektirir . Anladığım kadarıyla, o zamandan beri yaygın bir uygulama haline geldi.

Josh Smith'ten bahsettiğiniz için PropertyChanged sınıfına bir göz atın . Modelin INotifyPropertyChanged.PropertyChangedetkinliğine abone olmak için yardımcı bir sınıftır .

Yakın zamanda PropertiesUpdater sınıfımı oluşturarak yaptığım gibi, bu yaklaşımı daha da ileriye taşıyabilirsiniz . Görünüm modelindeki özellikler, model üzerinde bir veya daha fazla özellik içeren karmaşık ifadeler olarak hesaplanır.

INotifyPropertyChanged uygulamasında yanlış bir şey yokModel içinde ve onu ViewModel içinde dinlemek . Aslında, XAML'de modelin özelliğine bile girebilirsiniz: {Binding Model.ModelProperty}

Bağımlı / hesaplanmış salt okunur özelliklere gelince, bundan daha iyi ve daha basit bir şey görmedim: https://github.com/StephenCleary/CalculatedProperties . Çok basit ama inanılmaz derecede kullanışlı, gerçekten "MVVM için Excel formülleri" - Excel'in değişiklikleri sizin tarafınızdan fazladan çaba göstermeden formül hücrelerine yaymasıyla aynı şekilde çalışır.

Görünüm modelinin abone olması gereken modelden etkinlikler oluşturabilirsiniz.

Örneğin, yakın zamanda bir ağaç görünümü oluşturmam gereken bir proje üzerinde çalıştım (doğal olarak, modelin hiyerarşik bir doğası vardı). Modelde gözlemlenebilir bir koleksiyonum vardı.ChildElements .

Görünüm modelinde, modeldeki nesneye bir referans kaydetmiştim CollectionChangedve gözlemlenebilir koleksiyon olayına abone olmuştum , örneğin: ModelObject.ChildElements.CollectionChanged += new CollectionChangedEventHandler(insert function reference here)...

Ardından, modelde bir değişiklik olduğunda görünüm modeliniz otomatik olarak bilgilendirilir. Aynı konsepti kullanarak da takip edebilirsiniz PropertyChanged, ancak bunun çalışması için modelinizden açıkça özellik değişikliği olayları oluşturmanız gerekecektir.

Bu bana gerçekten önemli bir soru gibi görünüyor - bunu yapmak için herhangi bir baskı olmasa bile. TreeView içeren bir test projesi üzerinde çalışıyorum. Örneğin Sil gibi komutlarla eşleşen menü öğeleri vardır. Şu anda hem modeli hem de görünüm modelini görünüm modeli içinden güncelliyorum.

Örneğin,

public void DeleteItemExecute ()
{
    DesignObjectViewModel node = this.SelectedNode;    // Action is on selected item
    DocStructureManagement.DeleteNode(node.DesignObject); // Remove from application
    node.Remove();                                // Remove from view model
    Controller.UpdateDocument();                  // Signal document has changed
}

Bu basit, ancak çok temel bir kusuru var gibi görünüyor. Tipik bir birim testi komutu yürütür ve ardından sonucu görünüm modelinde kontrol eder. Ancak bu, ikisi aynı anda güncellendiği için model güncellemesinin doğru olup olmadığını test etmez.

Bu nedenle, model güncellemesinin bir görünüm modeli güncellemesini tetiklemesine izin vermek için PropertyObserver gibi teknikler kullanmak belki daha iyidir. Aynı birim testi artık yalnızca her iki işlem de başarılı olursa çalışacak.

Bunun potansiyel bir cevap olmadığını anlıyorum, ama ortaya koymaya değer görünüyor.