17 Haziran 2015 Çarşamba

MVC, MVP, MVVM Design Patterns nedir?

MVC (Model-View-Controller); Yazılım geliştirme teknolojilerinde kullanılan, Seperation Of Concern(Yazılımda işlev ve özelliklerin soyutlanarak birbirinden ayırılması) prensibini vurgulayan yazılım tasarım desenidir. İlk kez 1979 yılında “Trygve Reenskaug” tarafından tanımlanmıştır.

Kullanıcı View i görür, Controller ı kullanırlar. Controller Modeli manipule eder veya View i update eder. View, kullanıcı arayüzünü kullanıcıların görmesini ve Controller ı tetiklemesini sağlar.

Modelin Sorumlulukları: Property lerinde veri depolar, uygulama yöntemlerini implemente eder(data and logic), View 'ın register ve unregister methodlarını sağlar,View 'deki durum değişikliklerini uyarır, uygulamanın iş mantığının uygulanmasını sağlar.
View in Sorumlulukları: Arayüzü oluşturur, Model deki değişikliklerde arayüzü günceller, kullanıcı girişlerini Controller'a iletir.
Controller ın Sorumlulukları: Kullanıcı girişlerindeki değişiklikleri Modele iletir, eğer değişiklik yüzeysel ise View'i update eder.

MVP (Model-View-Presenter) ise; MVC de mimarisinde eksiklik olarak görülen sorunlara çözüm olarak 90’lı yıllarda ortaya çıkmıştır. İlk olarak Mike POTEL tarafından bir makalede popüler olmuştur. Daha sonra Martin Fowler ve Derek Greer tarafından da makalelerde ele alınmıştır. Daha sonrasında MVVM(Model View ViewModel) gibi mimari tasarım desenlerine de ihtiyaç duyulmuştur. İhtiyaca göre halen yeni pattern lar geliştirilmeye devam edilmektedir.
                              Şekil : Model View ViewModel
            MVC ‘deki Controller ın View ile daha az etkileşimde olduğu farkedilerek, Controller ın yerine Presenter katmanı tasarlanmıştır. Controller dan farklı olarak Presenter katmanı View ile direkt olarak etkileşim halinde dir.
Şekil : Genel MVP Design Pattern gösterimi.
MVP tasarımı deseni, view’in sorumluluğunu biraz daha arttırarak Controller sınıfını ortadan kaldırmıştır. View’deki veri durum yönetimini ve kullanıcıdan gelen komutları işlemek için presenter sınıfı bulunmaktadır. Presenter ve view arasında one-to-one bir ilişki bulunmaktadır. Bu sayede UI için test kodu yazmamız gerektiğinde ilgili Presenter’a test kodu yazabiliriz. Kullanıcı View’den isteği yaptığında bu istek önce ilgili Presenter sınıfına düşer. Presenter bu isteği modele göndererek dönen cevaba göreView’i update eder.
Passive View (PV) Yaklaşımı :
MVP’nin uygulanmasıyla alakalı iki farklı yaklaşım vardır. Bunlardan biri Supervising Controller olarak adlandırılmıştır. İki yaklaşımda da durum yönetimi View üzerinde yapılır, Presenter sınıfı View’den haberdardır.


Passive view yaklaşımında Presenter sınıfı View ile Modelin arasındaki senkronizasyondan tamamen sorumludur. View sınıfının model ile en ufak bir ilişkisi yoktur. Bütün iş mantığı Presenter sınıfı üzerinde yapılır. Bütün senkronizasyonu Presenter sınıfı sağlar. Bu yaklaşımında View’in çok fazla bir sorumluluğu yoktur. Yaklaşımın adından da anlaşılabileceği gibi pasif kalmıştır. View kendisinin değiştiğini bir event fırlatarak Presenter sınıfına haber verir. Presenter da ilgili model sınıfını günceller.
Supervising Controller (SC) Yaklaşımı :
Supervising Controller yaklaşımında ise, Presenter kompleks UI iş mantığını barındırır. View, modele binding mekanizması olan bir teknolojiyle bağlanarak veriyi çeker. Presenter sınıfı, view tarafından çağırılabilecek olan metotlara sahiptir. Controller sınıfındaki gibi hangi View’in gösterileceğine Presenter sınıfı karar vermez. Presenter sınıfının çağırılması için View’den kod yazılması gerekir. Bir View metodu, Presenter sınıfı tarafından çağırılabilir.
UI için test yazılması gereken projelerde MVP tasarım kalıbı kullanmamız MVC’ye göre daha uygun olur. Çünkü, bütün UI iş mantığı, Presenter sınıfı içerisindedir. Yani Presenter, bir nevi UI’ın kendisi durumundadır. Birden fazla UI teknolojisiyle çalışmamız gereken zaman MVP kullanmak daha mantıklıdır. Çünkü, Presenter sınıflarımız yeniden kullanılabilirliği arttıracaktır. Son derece kompleks UI iş mantığınız varsa veya kullanıcıyla etkileşimi yoğun olan sayfalarınız projenizin büyük bir çoğunluğunda yaygınsa; burada MVP tasarım kalıbı kullanmanın avantajı olacaktır. Bütün iş mantığı sayfanın Presenter sınıfında olacağı için işlem yapmak daha kolay olur. Test edilebilirlik uygulamanız için önemliyse o zaman Passive View yaklaşımı tercih edilmelidir. Çünkü bütün işleyiş onun üzerinde gerçekleşecektir. Ancak, kodun okunabilirliği, daha az karmaşık olması, test edilebilirlikten daha önemliyse, o zaman Supervising Controller yaklaşımı tercih edilmelidir. Çünkü, burada sorumluluğun bir kısmı Presenter sınıfının üzerinden alınmıştır. View ile model arasında bir binding mekanizması kurularak senkronizasyon sağlanmıştır. View sınıfındaki her değişiklikte Presenter sınıfının güncellenmesi gerekmeyecektir.

Çok Katmanlı Design Pattern Mimarilerinin Faydaları:
  1. Kod karmaşasının önüne geçer,
  2. Her katmanda ayrıca kod geliştirmeye izin verir(Front-end, back-end development),
  3. Daha rahat test edilebilir uygulamalar geliştirebilmeyi sağlar,
  4. Yazılım Mimarisi olarak, sorumlulukların birbirinden bağımsız olarak paylaştırılması, geliştirilecek olan yazılımın yönetimini, ölçeklenebilirliğini, geliştirme hızını artırır, bakımını kolaylaştırır.


Kaynaklar:

Gönderen zaman:
Etiketler: , , ,

Hiç yorum yok :

Yorum Gönder

Kaydol: Kayıt Yorumları ( Atom )