MVVM II : Hello World

Serinin önceki yazıları

• Bölüm 1 : http://cenkozdemir.blogspot.com/2010/11/mvvm-i-hey-bu-da-nereden-ckt-simdi.html

MVVM serisinin ikinci bölümüyle birlikte konuya hızlı bir şekilde kaldığımız yerden devam ediyoruz. Bir önceki bölümde MVVM’in ne tür bir mimari desen olduğu, temel bir kaç kuralı, avantajları ve dezavantajları gibi noktalara değinmiştik. Bu bölümde ise, basit bir “Hello World” uygulaması üzerinden View ve ViewModel kavramlarını anlamaya çalışacağız. Ayrıca View ve ViewModel arasındaki çok önemli iki etkileşim olan Notifiable Property ve Command’in nasıl oluşturulduklarını da öğreneceğiz.

Örnek uygulama Visual Studio 2010 IDE ’si üzerinde Silverlight 4 ile gerçekleştirilecek ve MVVM Toolkit’de yer alan kütüphaneler kullanılacaktır. Dolayısıyla başlamadan önce Toolkit’in kurulması gerektiğini hatırlatmakta fayda var. Laurent Bugnion’ın hazırladığı MVVM Toolkit’i ile ilgili daha ayrıntılı bilgi almak için serinin ilk yazısını incelemenizi tavsiye ederim.

Artık hazır olduğumuza göre, MVVM dünyasına giriş yapmak üzere “Hello World” projemizi oluşturabiliriz. Bu ilk örnekte, felsefenin aslını daha rahat görebilmek için, az sayıda kontrol ve iş içeren, oldukça sade bir arayüz üzerinden hareket edeceğiz. Hedefimiz ise, kullanıcının Button’a her tıklamasında, TextBlock’taki sayının bir arttığı basit bir Silverlight uygulaması geliştirmek. Örneğe geçmeden önce izlenecek yöntemle ilgili birkaç noktanın da altını çizmekte fayda var. İçinizden “Ne var bunda, + butonuna çift tıklar, oluşan metoda birkaç satır kod ekler ve hallederim” dediğinizi duyar gibiyim; ancak asıl amaç bahsi geçen bu minik programı MVVM mimari desenini takip ederek geliştirmek.

Klasik yaklaşım düşünüldüğünde, bu basit örnek, aşağıdaki adımlar izlenerek rahatlıkla yapılabilir.

1. Button kontrolünün Click olayına bağlanmak üzere, sayfanın içinde bir metot oluştur.
2. Oluşturulan metotta, TextBlock kontrolünün Text özelliğini okuyarak, mevcut değeri bir tamsayı değişkene ata.
3. Değişkende saklanan değeri bir arttır.
4. Yeni değeri string’e dönüştür ve tekrar TextBlock kontrolünün Text özelliğine ata.

Bu durumda yazılması gereken metot da aşağıdakine benzer olacaktır :

private void button1_Click(object sender, RoutedEventArgs e)
{
    int deger = int.Parse(textBlock1.Text);
    deger++;
    textBlock1.Text = deger.ToString();
}

Yukarıdaki metodun yazılması ve Click olayına bağlanmasıyla, hiç şüphesiz ekranda görünen sayının artması sağlanır; ancak söz konusu proje daha büyük olduğunda, izlenen bu yolun birçok dezavantajı bulunmaktadır. Arayüzde gerçekleşen işlerin (Business Logic) kodlanmaları sırasında kontrollere erişmek ve kontrolleri hedefleyen kodlar çalıştırmak bahsi geçen dezavantajların temelini oluşturmaktadır. Herşeyden önce bu yaklaşımın izlendiği projelerde, tasarımcılar ile programcıların bir arada çalışmaları daha güçtür. Örneğin, tasarımcı XAML içerisinde bir elemente Name niteliğini uygulayarak yeni bir isim verdiğinde, programcının kod tarafında ilgili elemente erişmek için kullandığı field’ın da adı değişecektir, dolayısıyla tasarımcının yaptığı basit bir isim değişikliği dahi problem oluşturabilmektedir. Bir başka örnek : Tasarımcı bir DataGrid’in kolon sırasını değiştirdiğinde, programcının ilgili kolonlardaki değerleri okumasında, kolon indeksleri değiştiğinden bir takım hatalar meydana gelebilir; hatta farkedilmesi güç, mantıksal hatalar dahi oluşabilir. Bunun yanı sıra, bahsi geçen klasik yöntemin, “önce A yapılır biter, sonra B başlar” yerine, Agile yaklaşımların benimsendiği projelerde daha fazla can sıktığını da söyleyebilirim.

Tabi ki dezavantajlar, yalnızca tasarımcı – programcı entegrasyonuyla da ilgili değildir. Klasik yaklaşım izlenerek oluşturulan bir projede, programcı hem kontrollere hem de diğer nesnelere ilişkin kodlamalar yapmaktadır. Dolayısıyla programcı, çekirdek iş mantığı bir yana; arayüzde yer alan kontroller, giriş değerleri için yapılan tip dönüşümleri, hesaplanan sonuçların kontrollere bağlanmaları vb. bir çok yan işlemi de düşünmek ve ele almak zorundadır. Hal böyle olunca, kişi, iş mantığından uzaklaşabilir, hatalar yapabilir ve basit bir takım geliştirmeleri yaparken bile gereksiz vakit harcayabilir.

MVVM tam olarak bu noktada devreye girmekte ve kodlamanın, tasarımdan bağımsız hale getirilmesi için bir çözüm sunmaktadır.  Temel hedef, iş mantığı ile görsel elementlerin bağımsızlığını sağlamak olduğundan, MVVM öncelikle iş mantığı ile görsel elementleri iki keskin kavramla birbirlerinden ayırmaktadır: View ve ViewModel. View, yalnızca görsel elementleri içermekte olup, tüm iş mantığı ViewModel’de yer almaktadır. Kilit nokta, ViewModel’in View’i tanımamasıdır. Diğer bir deyişle ViewModel’in kodlanması sırasında View’de yer alan kontroller dikkate alınmaz, hatta kontrollere erişilemez, yalnızca yapılan işlere odaklanılır.

Klasik yaklaşım ve doğurduğu temel dezavantajları ile MVVM programcısının bakış açısından bahsettiğimize göre, uygulamanın MVVM deseni kullanılarak oluşturulmasına nihayet başlayabiliriz.

Hello MVVM

Yeni bir Silverlight Application projesi başlatarak, öncelikle MVVM Toolkit’ini kullanmak üzere gerekli kütüphaneleri referans edelim.

Ardından MainPage’i aşağıdaki XAML kodlarıyla oluşturalım.

<Grid x:Name="LayoutRoot" Background="White">
       <Button Content="+" Height="23" HorizontalAlignment="Left" Margin="64,92,0,0"  VerticalAlignment="Top" Width="75"  />
       <TextBlock Height="44" FontSize="30" HorizontalAlignment="Left" Margin="153,82,0,0" Text="TextBlock" VerticalAlignment="Top" />
</Grid>

ViewModel’in Oluşturulması

Yukarıdaki XAML kodlarından faydalanarak arayüzü tamamladıktan sonra, projeye,  MainPageViewModel olarak isimlendirdiğimiz bir Class ekleyelim. MVVM tasarım deseni düşünüldüğünde MainPage, View; MainPageViewModel ise onun ViewModel’i; diğer bir deyişle, MainPage’deki işlerin, elementlere erişmeksizin kodlandığı yer olacaktır.

public class MainPageViewModel : GalaSoft.MvvmLight.ViewModelBase
{ }

Oluşturulan MainPageViewModel sınıfının, MVVM Toolkit kütüphanelerini referans ederek ulaştığımız ViewModelBase sınıfından kalıtıldığına da dikkat etmek gerekir. ViewModelBase, tüm ViewModel sınıflarının kalıtılacakları taban sınıftır ve her bir ViewModel’de ihtiyaç duyulan bir takım ortak üyeleri içermektedir.

ViewModelBase taban sınıfıyla ilgili bilinmesi gereken bir diğer özellik de, sınıfın, WPF ve Silverlight’ta veri bağlamasından hatırlayacağımız INotifyPropertyChanged arayüzünü uygulamış olmasıdır.

abstract class ViewModelBase : INotifyPropertyChanged, ICleanup, IDisposable
{ … }

Bu durumda oluşturulan MainPageViewModel sınıfı da kalıtım prensibi gereği, property değişiklerini arayüze haber verebilir niteliktedir. Yazının şu aşamasında çok da gerekli olmayan bu bilgi, örnek ilerledikçe çok önemli bir hal alacağından, şimdiden kulağa küpe yapılması şiddetle tavsiye edilir

---

MVVM Toolkit’i kullanmak yerine, kendi MVVM kütüphanenizi oluşturmanız halinde, tüm ViewModel’lere taban sınıf olma görevi gören ve INotifyPropertyChanged arayüzünü uygulayan ViewModelBase sınıfını da sizin sıfırdan oluşturmanız gerekir.

---

Bir ViewModel’in kodlamasına, View’de yer alan durum bilgileri ile kullanıcının tetikleyeceği işlemleri belirleyerek başlanmalıdır. Bu şekilde düşünüldüğünde, MainPage’de bir adet Int32 tipinden değerin tutulması gerektiği söylenebilir. Tabi ki bir de kullanıcı tarafından tetiklenmesi istenen, sayı arttırma işi söz konusudur. Özetle MainPageViewModel’de bir tane Int32 tipinden değer tutulması gerekirken, bir de bu değerin arttırılmasını sağlayan eylem bulunmalıdır. Belirlenen bu iki nokta, aslında ViewModel tasarımı açısından da iki yeni kavramı beraberinde getirmektedir:

1. Notifiable Property : Arayüzde yer alan her bir durum bilgisi için oluşturulan ve değer değişikliklerini arayüze haber verebilen property’dir. Durum değeriyle aynı tipte oluşturulur. O halde örnekte kullandığımız MainPageViewModel sınıfına, Int32 tipinden bir Notifiable Property tanımlanması gerekmektedir.
2. Command : Kullanıcının tetikleyeceği her bir “eylem” için oluşturulan, RelayCommand tipindeki özel property’lerdir. Her bir Command  tek bir işi ifade etmektedir. Dolayısıyla örnekte yer alan MainPageViewModel sınıfına, sayının arttırılmasına karşılık bir Command eklenmelidir.

Sayının değerini tutacak Notifiable Property’nin ViewModel’de tanımlanması için aşağıdaki kodların sınıfa eklenmesi yeterlidir.

public class MainPageViewModel : GalaSoft.MvvmLight.ViewModelBase
{
       int _sayi;

       public int Sayi
       {
           get { return _sayi; }
           set
           {
               if (_sayi == value)
                   return;

               _sayi = value;
               //RaisePropertyChanged metodu, ViewModelBase sınıfında tanımlı bir metot olup, INotifyPropertyChanged arayüzüyle gelen PropertyChanged olayının tetiklenmesini sağlamaktadır. Böylece, arayüzde Sayi özelliğine bağlanmış elementlere değerin değiştiği haberi ulaşacaktır.
               base.RaisePropertyChanged("Sayi");
           }
       } 
}

Dikkat edilirse, sınıfa eklenen Sayi isimli üye, sıradan bir property olmasıyla birlikte, tek önemli farkı, RaisePropertyChanged metodu aracılığıyla meydana gelen değer değişikliklerini arayüze bildirmesidir. Böylece Sayi’ya bağlanmış elementler, sayının değişmesi durumunda bu değişiklikten haberdar olacaklar ve yenilenerek son değeri görüntüleyebileceklerdir.

Sayi property’sinin oluşturulmasından sonra geriye, yalnızca, sayının arttırılmasını sağlayacak Command’i tanımlamak kalmaktadır. Yukarıda da belirtildiği üzere ViewModel içerisinde bir Command tanımı yapmak için, RelayCommand tipinden bir property’nin oluşturulması gerekmektedir. Diğer bir deyişle her bir RelayCommand tipinden property, arayüzde, kullanıcının tetikleyeceği bir eylemi ifade etmektedir.

---

MVVM Toolkit kütüphanelerinde yer alan ViewModelBase ve RelayCommand sınıfları, farklı MVVM kütüphanelerinde farklı isimlerle bulunabilirler.  Sınıf isimlerinden ziyade bu sınıfların görevlerini kavramak daha doğru olacaktır. ViewModelBase, tüm ViewModel’lerin taban sınıfıdır, RelayCommand ise kullanıcının tetikleyeceği her bir eylemi ifade etmek üzere kullanılan sınıftır.

---

Sayı arttırma işini ifade edecek Command’in oluşturulması için, MainPageViewModel sınıfına SayiArttirCommand isimli RelayCommand tipinden property aşağıdaki gibi eklenebilir.

//Command
public RelayCommand SayiArttirCommand { get; set; }

Tabi ki SayiArttirCommand tetiklendiğinde yapılacak işi de bir yerde tanımlamak gerekir. Bunun için ViewModel’in Constructor’ında bir RelayCommand nesnesi örnekleyerek komut oluşturulmalı ve çalıştırılması istenen metot belirtilmelidir.

Ekran görüntüsünden de farkedileceği üzere, RelayCommand nesnesinin örneklenmesi sırasında Action tipinden bir parametre gönderilmelidir. .NET Framework içerisinde yer alan Action tipi, void() imzasına sahip metotları işaret eden bir delege olup, bu örnekte, butona tıklandığında çalışması istenen metodun adresini saklamak üzere kullanılmaktadır. RelayCommand nesnesine parametre olarak geçilen bu metot, ViewModel sınıfında tanımlanabileceği gibi anonim olarak da yazılabilir. Bu bilgiler ışığında kodlar düzenlediğinde, Constructor metodun son şekli aşağıdaki gibi olacaktır.

public MainPageViewModel()
{
    SayiArttirCommand = new RelayCommand(() => Sayi++);
}

---

Bazı durumlarda komut çalıştırılmadan önce bir takım koşulların sağlanıp sağlanmadığını kontrol etmek gerekebilir. Böyle bir ihtiyaç söz konusu olduğunda, geriye bool dönen bir metot tanımlayarak, RelayCommand’in oluşturulması sırasında Constructor’a ikinci parametre olarak belirtilir. Bu kullanım şekli, serinin devam eden yazılarında da incelenecektir.

---

Evet, nihayet ViewModel’in hazırlanması tamamlandığına göre, sınıfın son halini görebilir, bazı önemli noktaların altını çizebiliriz.

public class MainPageViewModel : GalaSoft.MvvmLight.ViewModelBase
{ 
    int _sayi;
    public int Sayi
    {
        get { return _sayi; }
        set
        {
            if (_sayi == value)
                return;

            _sayi = value;
            base.RaisePropertyChanged("Sayi");
        }
    }

    public RelayCommand SayiArttirCommand { get; set; }

    public MainPageViewModel()
    {
        SayiArttirCommand = new RelayCommand(() => Sayi++);
    }
}

Dikkat edilmesi gereken önemli noktalar şunlardır :

• Kodlamayı yaparken arayüzdeki elementlere erişmeyiz.
• ViewModel’in oluşturulmasında tasarımdan bağımsız bir bakış açımız olmalı : “Bir Int32 değer var ve kullanıcının ekrandaki bir tetiklemesiyle bu değer birer birer artacak”
• Arayüzde tutulan durum bilgileri için Notifiable Property oluşturulur.
• Arayüzde kullanıcının tetikleyeceği sayı arttırma işi için Relay Command nesnesi oluşturulur.
• Oluşturulan RelayCommand, kullanıcı butona tıkladığında çalıştırılacak metodu, Action delegesi aracılığıyla işaret etmektedir.

ViewModel’in View’e Referans Edilmesi

ViewModel’in tamamlanmasıyla, arayüze ilişkin tüm kodlama da tamamlanmıştır. Bu noktadan sonra tek yapılması gereken, View ile ViewModel’i arasındaki etkileşimleri belirtmektir. Tabi ki öncelikle View’in, kendisine ait ViewModel’i örneklemesi ve referans etmesi gerekmektedir. Bu amaçla, MainPage’in Constructor’ında aşağıda görülen düzenlemeler yapılmalıdır.

public partial class MainPage : UserControl
{
    public MainPage()
    {
        InitializeComponent();

        DataContext = new MainPageViewModel();
    }  
}

Aslında yapılan işlem oldukça basittir. MainPage, yani View, MainPageViewModel nesnesini, yani ViewModel’ini oluşturmuş ve sonrasında oluşan nesneye ait referansı DataContext property’sine atamıştır. Böylelikle MainPage’de yer alan elementler ile MainPageViewModel’de yer alan property’ler arasında, aşağıdaki şemada, oklarla belirtilen Binding ilişkileri kolayca oluşturulabilecektir.

Şemada görülen Binding ‘leri tanımlamak için tek yapılması gereken; TextBlock’un Text değeri ile Button’ın Command property’lerini, DataContext’te yer alan MainPageViewModel nesnesinin ilgili property’lerine Binding Markup Extension’ını kullanarak bağlamaktır.

<Grid x:Name="LayoutRoot" Background="White">
    <Button Content="+" Height="23" HorizontalAlignment="Left" Margin="64,92,0,0" VerticalAlignment="Top" Width="75" Command="{Binding SayiArttirCommand}" />
    <TextBlock Height="44" FontSize="30" HorizontalAlignment="Left" Margin="153,82,0,0"  Text="{Binding Sayi}" VerticalAlignment="Top" />
</Grid>

Hepsi bu kadar Gerekli Binding kurallarını belirttikten sonra uygulamanın son halini çalıştırırsanız, MVVM desenini kullanarak hedeflenen noktaya ulaştığımızı siz de test ederek görebilirsiniz.

 

Programın çalışma zamanındaki akışını ise aşağıdaki şemada inceleyebilirsiniz.

Böylece geldik bir makalenin daha sonuna. Bu yazıda çok basit bir Silverlight uygulamasını MVVM mimari desenini kullanarak oluşturduk ve konuya “Hello World” tadında bir giriş yaptık. Bir sonraki yazı itibariyle MVVM serisine kaldığımız noktadan hızla devam edeceğiz.

Faydalı olması dileğiyle…

MVVM I : Hey, bu da nereden çıktı şimdi?

WPF ve Silverlight’ın arayüz programlaması için oldukça güçlü alternatifler olarak yazılım projelerinde yer almaya başladıkları şu günlerde, geliştirme yapan herkesin çok işine yarayacağını düşündüğüm seriye nihayet bu yazıyla birlikte başlıyoruz. Önümüzde uzun bir yol olacak ve bu uzun yol boyunca MVVM desenini geliştireceğimiz uygulamalar eşliğinde öğrenmeye çalışacağız. Serinin bu ilk yazısında ise, MVVM’in teknik olarak detaylı bir incelemesini yapmak yerine,  konuya kısa bir giriş yapacak ve bazı temel sorulara cevap arayacağız.

Bir yazılımda geliştirme yapan ekipler çoğu zaman en az iki kişiden oluşmakta olup, yazılan kod satırları da yine çoğu zaman birkaç bini aşmaktadır. Bu sebeple projede yer alan tüm üyelerin, geliştirme sürecinde, ortak kuralları kabul etmeleri ve bu kuralların doğurduğu kısıtlamalar dahilinde hareket etmeleri oldukça önemlidir. Böylece programcılar karşılaştıkları problemlere kendilerince çözümler getirmeleri yerine, önceden tanımlı desenleri kendi problemlerine uygulayarak, genel bir standartın oluşmasına olanak sağlarlar. 

Katmanlı mimari kullanılarak geliştirilen yazılımların sunum katmanları (Presentation Layer) için sıkça başvurulan tasarım desenleri aşağıda listelenmiştir :

• Page Controller
• Front Controller
• Model-View-Controller (MVC)
• Application Controller
• Observer
• Model-View-ViewModel (MVVM)

Bingooooo O halde MVVM’in sunum katmanının tasarlanmasında yararlanılan bir desen olduğunu söylemek doğru olacaktır. Hatta tam doğru bir tanım için şöyle söylenmelidir: “MVVM, WPF ve Silverlight uygulamalarında sunum katmanının oluşturulması için kullanılan bir mimari desendir.”

MVVM tasarım deseni Microsoft’un WPF takımından John Gossman tarafından yaratılmış olup, MVC’nin bir varyasyonu olarak düşünülebilir. Aynı zaman da Martin Fowler’ın PresentationModel ‘ine de oldukça benzemektedir.

MVVM’in temel hedefi, programda yer alan görsel elementler ile (UserControl, Page, Control, Window vb.), bu elementlerin kullanıcıyla etkileşimlerine ilişkin kodlamayı birbirlerinden en keskin şekilde ayırmaktır. Geleneksel arayüz programlamasında, bir ekrana ait iş mantıkları, o ekranın code-behind dosyasında kodlanırken, MVVM’de tam aksine code-behind ‘ın temiz kalması hedeflenir. “Nasıl yani?” dediğinizi duyar gibiyim, ancak bu sorunun cevabını bir sonraki yazıya bırakarak kaldığımız yerden devam edelim.

MVVM tasarım deseninin uygulanması

Bir WPF/Silverlight projesinde MVVM desenini kullanabilmek için, öncelikle bir MVVM kütüphanesi oluşturmak gerekir. MVVM kütüphanesi, tasarım deseninin projeye uygulanabilmesi için gerekli tipleri içerecektir. Bu noktada programcı ya kendi MVVM kütüphanesini sıfırdan geliştirmeli ya da var olan var olan kütüphanelerden birini tercih etmelidir. Çeşitli blog’larda ve Codeplex gibi açık kaynak kodlu projelerin paylaşıldıkları sitelerde farklı MVVM kütüphaneleri bulunabilmektedir. Bu kütüphanelerin tümü özünde aynı olmalarına rağmen, bazıları Code-snippet, Project Templates gibi ekstra özellikler sağlayarak ve önemlisi geliştirilmesi sürerek (yeni versiyonları yayınlanarak) ön plana çıkmaktadır.

Bizler bu yazı dizisinde gerçekleştireceğimiz projelerde MVVM kütüphanesi olarak, Laurent Bugnion’ın hazırladığı, http://www.galasoft.ch/mvvm/getstarted/ adresinden bilgi edinilebilen, açık kaynak kodlu MVVM Toolkit’ini kullanacağız. Bugnion’ın  MVVM Toolkit’i, desenin projeye uygulanması için gerekli DLL’lerin hem Silverlight hem de WPF versiyonlarına sahip olmakla birlikte, ayrıca işleri kolaylaştıran Visual Studio ve Expression Blend eklentilerini de içeriyor. Toolkit’in öne çıkan özelliklerini listelersek :

• Hem Silverlight hem WPF için kullanılabilir olması
• Kod yazımını çok kolaylaştıran çeşitli Code Snippet’lar
• Geliştirilmeye devam edilmesi
• Design-Time desteği
• Dökümantasyon
• Hem Visual Studio hem de Blend için proje şablonları
• Windows Phone 7 geliştirmesi için VS2010 ve Blend desteği 

MVVM yazı dizisinde yapacağımız örnek projelerde bu toolkit’i kullanacağımız için, sizler de aşağıdaki adresten gerekli dosyaları indirerek, projeleri kendi bilgisayarınızda çalıştırabilir ve örnekleri bizzat test edebilirsiniz.

http://mvvmlight.codeplex.com/

Model-View-ViewModel

MVVM’in açılımı olan Model, View ve ViewModel’in  ne anlama geldiklerini zaten serinin devam eden yazılarında detaylı inceleyeceğiz, ancak bu giriş yazısında, kavramların biraz daha oturması amacıyla MVVM’i oluşturan baş harflerden bahsetmekte fayda var.

1. View : Programın arayüzünü oluşturan formlar, MVVM’de View olarak anılmaktadırlar. Bir View, Silverlight Page, UserControl, Window, DataTemplate vb. herhangi bir tip olabilir. Önemli olan, nesnenin, çalışma anında bir görüntü üretiyor oluşudur.
2. ViewModel : Bir View’ın, tüm iş mantığını barındıran tipe ViewModel denmektedir. Özetle View ile Model arasındaki bağlantıyı sağlar ve View’in durum bilgisini korur. ViewModel felsefesi şunu amaçlar : “Bu sınıfta kontrollere erişmeden, dolayısıyla kontrolleri hiç düşünmeden sadece iş mantığını kodla!” .
3. Model : Basit bir ürün düzenleme formunu (View) kodlarken (ViewModel), bir Urun sınıfının oluşturulması ve ürünlere ait özelliklerin, property olarak Urun sınıfına eklenmesi söz konusudur. Bu durumda  View’’de yer alan elementleri, her biri birbirinden bağımsız bir int, bir string bir decimal’a değere bağlamak yerine, bir Urun nesnesine bağlanması çok daha doğrudur. Bu durumda yazılan Urun sınıfının Model sınıf olduğu söylenebilir. Model sınıfların özel olarak bir takım Attribute’larla işaretlenme zorunluluğu da yoktur. Diğer bir deyişle POCO sınıfı dahi bir Model olarak olarak kullanılabilir; ancak çoğu zaman model sınıflar ya servis referansının eklenmesiyle otomatik üretilir ya da bir ORM aracıyla oluşturulur.

Model, View ve ViewModel ile ilgili bilinmesi gereken çok önemli iki altın kuralı da atlamamak gerekir. Bunlar :

1. View, ViewModel’i bilir, fakat tersi söz konusu değildir.
   View’de bulunan elementler, ViewModel’de tanımlı üyelere Bind edileceklerinden, View’in ViewModel’i bildiğini söyleyebiliriz; ancak ViewModel kesinlikle View’de yer alan elementlere erişmez ve View’de ne olduğunu bilmez.
2. ViewModel, Model’i bilir, fakat tersi söz konusu değildir.
   ViewModel, Model’in, örneğin bir Urun sınıfının üyelerine erişebilir ve kullanabilir, yani kısaca ViewModel, Model’i bilir; fakat Model’de yer alan sınıf içinde ViewModel’le ilgili herhangi bir kod bulunmaz.

MVVM’in Avantajları

• ViewModel kodlama alışkanlığı, geliştiriciye, iş mantığına odaklanma zorunluluğu ve disiplinini kazandırır.
• Arayüzde verilerin alınmasını (input) ve görüntülenmesini (output) sağlayan kontroller değişse de iş mantığı değişmedikçe ViewModel’de bir değişiklik yapılmasına gerek yoktur.  Sonuç olarak, Görünüm ve İşler’in keskin bir şekilde ayrılması hem yönetilebilirliği arttırır hem de olası bir değişiklikliğin daha kolay uygulanabilmesini sağlar.
• MVVM tasarımının uygulandığı WPF ya da Silverlight uygulamalarında Expression Blend’in becerileri  daha etkin kullanılabilmektedir. View’in “Blendability” ‘si yükselir
• XAML içinde yapılan Binding’ler ile, kontrollere değer bağlama işlemi oldukça kolaylaşmaktadır. MVVM, Binding kullanımlarını en üst düzeye çıkartarak, kod dosyasındaki veri bağlama işlerini kod tekrarı olmadan ve çok konforlu bir biçimde yapılmasını sağlar.
• İş mantığı arayüzden bağımsız olduğundan, programın test edilmesi çok daha kolaydır. Yani daha bir  “Testable” ‘dır
• Tasarımcılar ile programcıların aynı projede eş zamanlı çalışmalarını daha etkili hale getirir.

MVVM’in Dezavantajları

• ViewModel’de kontrollere erişememek, zaman zaman işi zorlaştırabilir. Bu tarz durumlarla çok karşılaşmamak için MVVM’i iyi anlamak ve benzer problemlere nasıl çözümler önerildiğini okumak, araştırmak gerekir.
• Zaman zaman yazılan kod satır sayısının artmasına sebep olabilir; ancak code snippet’ları kullanmaya alıştığınızda bu durum artık bir dezavantaj olmayacaktır.

Serinin bir sonraki yazısı itibariyle, örnekler üzerinden MVVM’i konuşmaya ve avantajlarını anlamaya devam edeceğiz. Öğrendiklerinizi kısaca bir gözden geçirmek üzere, MVVM’in temel kavramlarına kısaca değinmiş olduğumuz bu bölümdeki bazı sorulara göz atabilirsiniz.

• MVVM nedir?
• Model, View, ViewModel kavramları ne anlama gelir?
• Model, View ve ViewModel arasındaki iki önemli kural nelerdir?
• Benzerlik gösterdiği diğer tasarım desenleri nelerdir?
• MVVM Toolkit nedir?
• Desenin avantaj ve dezavantajları nelerdir?

Faydalı olması dileğiyle…

At The Edge Of Time

Bugün blog’a şöyle bir baktım da yazılım dışında pek birşey paylaşmamışısız. Bu sebeple, biraz değişiklik olması iyi olur diye düşündüm ve müzik yazmaya karar verdim

Birçok farklı müzik türünü dinlesem ve sevsem de, ağırlıklı olarak Rock/Metal dinlerim. Bu müzik türünde de Blind Guardian’ın benim için ayrı bir yeri olduğunu itiraf etmeliyim.

Sevenleri bilir, çok sık albüm çıkarmaz bu arkadaşlar, 4 yılda bir yaparlar ama tam yaparlar. Grubun 2006 yılında yayınladığı “A Twist in the Myth” albümünden yine 4 yıl sonra,  yeni albüm “At the Edge of Time” 2010 Ağustos ayının başlarında yayınlandı.

"Sacred Worlds" — 9:17
"Tanelorn (Into the Void)" — 5:58
"Road of No Release" — 6.30
"Ride into Obsession" — 4.46
"Curse My Name" — 5:52
"Valkyries" — 6:38
"Control the Divine" — 5:26
"War of the Thrones" — 4:55
"A Voice in the Dark" — 5:41
"Wheel of Time" — 8:55

Gördüğünüz gibi, parçalar genelde uzun sayılabilecek süredeler. Özellikle 9:17’lik Sacred Worlds ve 8:55’lik Wheel of Time bu anlamda dikkatleri çekiyorlar. Bu iki parçanın neden açılış ve kapanış parçaları olarak seçildiklerini ise albümü dinlemeye başladığınızda anlıyorsunuz.

Albümdeki Wheel Of Time, tartışmasız favorim oldu. Doğu ezgileri, orkestra ve Hansi’nin sesi birleşince destansı bir parça çıkmış ortaya. And Then There Was Silence ile birlikte Blind Guardian’ın mihenk taşlarından biri kesinlikle.

Curse My Name, Tanelorn, Road of No Release, War of the Thrones, Control the Divine ve A Voice in the Dark da albümde en sık dinlediğim parçalar olarak MP3 oynatıcımda yerlerini aldılar:)

Bu arada unutmadan, ozanların 2 Nisan 2011’de tekrar Istanbul’da olacağını hatırlatmakta fayda var. Biletler de satışta :

http://www.biletix.com/event.htm?id=MLVMA