*

  • 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 uygulama çok azdır. 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.
  • yeni başladığım işte kullandığım android uygulama geliştirmeyi daha keyifli hale getiren ve (bkz: seperation of concerns) prensibini iliklerinize kadar hissettiğiniz dizayn metodu. tüm amaç kodu unit testing ve maintainability açısından daha kullanışlı hale getirmektir.
  • mvp'ye göre daha kullanışlı olan mimaridir ama ne yazık ki mvp mimarisi kadar yaygın değil. yeni yeni büyümeye başlayan mimari. kullanın, öğrenin efendim..
    ben kodumu yazarım çalışsın yeter mantığından bir kurtulun.
  • xamarin için konuşacak olursak, xaml.cs denilen dosya aslında view'ın partial class'ını oluşturduğundan, esasında view'un bir parçasıdır. diğer parçası ise xaml dosyasının yardımı ile arka planda generate edilir. viewmodel'in amacı view ve model arasındaki ilişkiyi tamamen ortadan kaldırmak, bunu yaparken de kendisinin view'dan herhangi bir şekilde haberdar olmamasını sağlamaktır.

    ideal bir mvvm düzeninde view, yalnızca bindingler aracılığı ile viewmodel'e bağlanır. tamamiyle aptaldır, taocudur, dombilidir. tek gayesi ekrana bir şeyler çizmektir. dolayısı ile view katmanında yapacağınız entity manipülasyonları, yazılan business logic kısımları, servis çağrıları mvvm mimarisine taban tabana terstir.

    gerçek bir mvvm projesi oldukça "loosely coupled" olduğundan, modelde yapacağınız bir değişiklik view'u etkilemek zorunda değildir, aynı şekilde viewmodel üzerinde yapacağınız bir değişiklik view'u etkileyebileceği gibi model'i etkilemeyebilir.

    ayrıca unit testing açısından da oldukça faideli bir arkadaştır.

    (bkz: loosely coupled)
    (bkz: unit testing)
  • android dünyası için;

    - view : activity, fragment
    - viewmodel, ui ile alakalı datayı lifecycle aware bir şekilde tutmayı sağlayan android özelinde geliştirilmiş viewmodel class'ı.

    - model ise basitçe data classları ya da pojolar olarak özetlenebilir. repository pattern uygulandığı takdirde local veya remote dataya ulaşım sağlayan repository classları da dahil edilebilir.

    (bkz: separation of concerns) konsepti için clean architecture'dan bir önceki durak olabilir. uygulama senaryosu ve proje büyüklüğüne göre clean architecture ile kombinlenebilir.
hesabın var mı? giriş yap