şükela:  tümü | bugün
  • pattern'i, mix10 isimli ms faaliyetinde, twitter rumuzu "eisenbergeffect" olan muhterem güzel bir şekilde anlatmıştır.
  • aslında presentation model'in wpf'in binding alt yapısına göre optimize edilmiş halinden başka birşey değildir. martin fowler 2004 yılında yazmış ;

    http://martinfowler.com/…dev/presentationmodel.html

    ayrıca konu hakkında yazdığım bir yazı var;

    http://www.denizirgin.com/…vc-mvp-mvvm-pattern.aspx
  • (bkz: knockout js)
  • jason dolinger'ın hakkında çok başarılı bir video hazırladığı tasarım desenidir.
    bakmak isteyenlere,
    jason dolinger - mvvm
  • kullanıcıyla etkileşim kuran bir uygulamanın "model", "view" ve "viewmodel" adındaki üç parçadan oluşmasını öngörür. ilk martin fowler ortaya atmış. martin abi ne dese doğrudur.

    model, uygulamanızın kullandığı ve işlediği veriyi temsil eden, onlar üzerinde işler yapan kodların bulunduğu class'ların her birine denir. mesela bir yapılacak işler listesi uygulamasında modeliniz:

    class yapilacakisler {
    public list<string> isler;
    }

    olabilir gayet. bu haliyle modelde diske kaydetme imkanı yok ama koymak istediğinizde onu da yapilacakisler sınıfının içine koyabilirsiniz.

    view, model'ın kullanıcıya nasıl gösterileceğini ifade eden şablonlara denir. bu da yapılacak işler örneğinden "liste" içeren bir xaml kodu olabilir, bir html şablonu olabilir. artık ne isterseniz.

    viewmodel: model'ınızı view'da gösterirken ek bilgilere, property'lere ya da dönüşüm kodlarına gerek olabilir. view ile model birbirinden ful bağımsız olması gerektiğinden bunları model'ınıza, ya da view'ün koduna eklemek yerine viewmodel denen yeni bir sınıf yaratırsınız. mesela "kaç yapılacak iş" olduğunu da view'da göstermek istiyorsunuz ama model'da doğrudan ona eşleşecek property yok. listenin count'una da doğrudan bind imkanı olmadığını farz edelim. o zaman şöyle bir yeni sınıf yaratıyoruz:

    class yapilacakislerviewmodel: yapilacakisler {
    public int kactaneyapilacakis => isler.count;
    }

    (public int a => b tarzı sözdizimi garip geldiyse o da c# 6.0'la gelen yeni sadeleştirilmiş sözdizimi. aslında özünde public int a { get { return b; } }'ye denk geliyor)

    isimde "viewmodel" olması tamamen ayrıştırmak için kolaylık olsun diye. siz bunlara dilerseniz "hobarak" diyebilirsiniz. view'u da doğrudan viewmodel'a bağladığınızda artık bu yeni property'yi de kullanabilir hale gelir. sizin de çekirdek uygulama veri yapılarında herhangi bir değişiklik yapmanıza gerek olmaz.
  • abartı beğendiğim bir arayüz kodlama pattern'i. gözlemlerim şunlar:

    - varabileceğiniz en üst düzey seviye, code behind'da sıfır kod yazarak her şeyi viewmodel ve view içinde halletmek, içinden çıkmak.
    - veritabanlık işleriniz varsa mutlaka intermediate sınıflar yazmalısınız, kaçış yok. örneğin bir orm kullanıyorsanız (bkz: entity framework) "direk o sınıfları kullanırım ya" ile çoğunlukla sonuç alınamıyor, arada illa bir veri conversion'ları falan gerekiyor. daha en başından üşenmeyip bu dto'ları yaratmakta fayda var.
    - bir viewmodel'ın aşırı şişmesi iyi değil. projeyi ayrı view ve viewmodel'lara ayırmakta fayda var.
    - viewmodel'ın test edilebilirliği manyak yükseliyor. unit test bilindiği gibi lisede seks gibidir, herkes hakkında konuşur ama kimse yazmaz. ola ki siz yazan küçük azınlıktaysanız sadece backend'i değil frontend'i de efsane test etme olanağı tanır.
    - wpf'deki kullanımında 2017'nin .net framework'ünde bile bir implementasyon eksiği mevcut ki bu binding'lerin güncellenmesinde zorluk çıkmasına neden oluyor. mvvm sınıfınızın inherit alacağı şöyle bir base class yazmanızda fayda var:

    public abstract class viewmodelbase : ınotifypropertychanged
    {
    public event propertychangedeventhandler propertychanged;

    protected void raisepropertychangedevent(string propertyname)
    {
    var handler = propertychanged;
    if (handler != null)
    handler(this, new propertychangedeventargs(propertyname));
    }

    daha sonra bir property güncellendiğinde raisepropertychangedeventhandler metodunu çağırarak görsel binding'lerin güncellenmesini sağlar. hatta bu property'lerin set'ine bunu yazarak her seferinde manuel olarak çağırmaktan da kurtulursunuz.
    - mvvm illa public property okumak ister, public değişkenleri okuyamaz, public metodları çağıramaz. private ile zaten işi olmaz, dikkat edin.

    mvc'den farkı şudur: mvc'de view ile controller iletişim halindedir. controller isterse servislere ya da factory'lere başvurur. mvvm'de ise durum farklıdır. view viewmodel kullanarak tamamen kendini izole edebilirken ihtiyaç halinde code behind ile de modifiye edilebilir. bu da developer'a mvc'de olmayan bir esneklik sunar. yine de ideal olan tüm kodu viewmodel'de yazmak ve code behind'dan uzak durmaktır.

    microsoft xaml ve mvvm'i her nereye koyduysa (wpf, windows phone, silverlight, xamarin) çok geniş kullanıcı kitlelerine ulaşamadı. dileğim mvvm'in ortadan hiç kaybolmaması ve sonsuza kadar bizlerle bulunması, 800 yıl sonra geliştirilecek zaman makinesinin frontend'ini kodlarken bile işin içinde bulunmasıdır.