Mobil Uygulama Geliştirirken Neden Mimari Odaklı Çalışmalıyız? (iOS)
Merhabalar herkese. Yeni ve güzel bir yazıyla daha karşınızdayım. Bugün sizlere mobil uygulama geliştirme süreçlerinde kritik olan bir konudan, mimarilerden bahsedeceğim.
Şu anda ikamet etmekte olduğumuz evlerimizi düşünelim. Genelde yemek yapmak için mutfağı, aile fertleriyle sosyalleşmek için salonu ve kitap okumak için şahsi odamızı kullanırız. Buradaki noktalarda yapılan iş ve işin yapıldığı yer büyük önem arz ediyor. Objektif açıdan bakıldığında yemeği salonda yapıp kitap okumayı da mutfakta ocağın yanında yapmayı pek tercih etmeyiz, takdir edersiniz ki verimli olmayacaktır :). Mobil uygulama geliştirme süreçlerinde de architecture’lar bize tıpkı bu örnekte olduğu gibi IDE üzerinde kurmak istediğimiz logicleri belirli görevleri olan küçük katmanlara ayırarak işlerimizin daha işlevli ve düzenli çalışmasını sağlıyor.
Yazılan kodların nasıl daha okunaklı ve reusable olması konusunda ve aslında ana fikir olarak bir mimari oluşturmanın neden gerekli olduğuna bakmak için birkaç mimari örneğinden ilerleyeceğim. Bu mimarileri önce açıklayıp daha sonra yorumlama yaparak gerekliliklerinden bahsedeceğim. Hadi başlayalım!
MVC (Model-View-Controller)
Bu mimarinin yazılım sektöründe çok önemli bir yere sahip olduğunu düşünüyorum. Birçok projede kullanılan ve aslında en sık tercih edilen bir mimari de diyebiliriz. Model, View ve Controller olmak üzere 3 ana iş parçacığından oluşmakta. Hadi gelin bu kavramları aşağıda beraber inceleyelim.
Model
Projelerdeki tüm business logic (iş mantığı) olayları genelde bu katmanda tutulur. Örneğin bir service provider üzerinden ya da database’den gelen datalar ile ilgili işlemler buradan yönetilebilir.
View
Son kullanıcıya servis edilen komponentlerin tümüdür. Bir diğer tanımla kullanıcı arayüzü diyebiliriz.
Controller
Model ve View arasında köprü görevi gören bir katmandır. MVC’nin bel kemiği diyebiliriz. Son kullanıcı aksiyonlarıyla View üzerinden alınan tüm datalar bu katman aracılığıyla Model’e taşınır. Son durumda tekrar bu katman yardımıyla dataların son hali View’a paslanarak son kullanıcıya aksiyonun sonucu gösterilir. Kısacası bu katman, bir ara katman görevi görerek Model ve View arasındaki data transferring işlemlerini kontrol eder. Tabii istendiğinde View katmanından Model katmanına erişim sağlanabilir ama ne kadar efektif olur orası ayrı bir makale konusu olsun :).
MVVM (Model-View-ViewModel)
Şu an kendimi sanki buraya bu mimarinin reklamını yapmaya gelmişim gibi hissediyorum. O derece hayranlık beslediğim bir mimari. Model ve View katmanlarını zaten MVC’de açıklığa kavuşturduğumuz için es geçiyorum. Sizlere buradaki en sihirli katmandan bahsedeceğim; View Model.
View Model
Bu katman MVC’deki Controller’a benzer bir yapıda. Fakat aralarındaki en temel farklılık MVC’deki Controller, View’ı hem okuyup hem değiştirebilirken, View Model katmanı yalnızca Model’i düzenler, üzerini sarmalayıp paketler ve daha sonra bunu View’a bildirerek üzerine düşen görevi gerçekleştirmiş olur. View ise son kullanıcıya veri akışının sonuçlarının gösterimini gerçekleştirir. Şekil 1.3'te bu yapıyı daha net bir şekilde görebiliriz.
Bu yazının amacı versus konusuna sapmadan önce şöyle bir örnekle yukarıdaki teorik bilgileri uygulamalı olarak hep birlikte pekiştirelim.
Bu kodda gördüğümüz üzere setupView metodu içerisinde for döngüsü içerisindeki if bloğuyla guitaristList dizisinin içerisinde “Jimi Hendrix” text’inin olup olmadığının kontrolü sağlanmaktadır. Eğer bulunması durumunda ise nameLabel adındaki UI objesine “Jimi Hendrix” text’inin yazdırılması istenilmiş. Şimdi bu kod bloklarını MVVM mimarisi prensiplerine göre biraz kendi yorumlarımızı da katarak parçalayalım.
Öncelikle MVVM için gerekli olan sınıfları oluşturmam gerekiyor. Bunun için daha önce Github hesabımdan paylaşmış olduğum KeyZim-MVVM Template ini kullanacağım.
GuitaristViewModel ve GuitaristModel sınıflarım oluşmuş durumda.
Şimdi bu sınıfları View Controller’ımızdaki kodlarla birlikte özelleştirelim. Öncelikle guitaristList bir property olduğu için doğrudan View Model içerisine taşıyorum. GuitaristName enum’ını taşımaya gerek duymuyorum fakat konuyu daha rahat kavramanız açısından ve kolay değişiklikler gerçekleştirebilmeniz için onu da ViewModel’e taşıyacağım.
View Model’imizin son haline bir bakalım.
Bence gayet iyi gidiyoruz. Şimdi View Controller içerisindeki setupView metodundaki for döngüsü bulunan blokları olduğu gibi View Model’e taşıyalım.
Dikkatli incelersek, bu for döngüsü için bir metot oluşturdum ve içerisinde if ile beraber kontrolünü sağladığım “guitarist” instance’ını View’a gönderebilmek için delegate yöntemine başvurdum.
View Controller’a bir extension ekleyerek bu extension’a delegate protokolümü inherit alıyorum. Ve tabiki diğer yandan bir View Model property’si oluşturarak bu sınıfın delegate’ini View Model’deki delegate ile eşlenik hale getiriyorum.
Şimdi bu noktada Model katmanını buraya nasıl entegre ederiz hemen onu da inceleyelim.
Her ne kadar hardcoded bir deneme de olsa burada sonuç olarak toplanan veri modelleri View Model tarafından sarmalandıktan sonra View’a formatlanmış şekilde sunulabilmiş olmasıdır. Ayrıca bir API’dan gelen response’ın modelleme işlemlerinde de bu yöntemin kullanılması büyük yarar sağlayacaktır. Belki bu konuyu da başka bir yazıda inceleriz :).
Umarım açıklayıcı bir yazı olmuştur. Uzun süredir bu minvalde bir yazı yazmayı düşünüyordum. Yazıda bir hata olduğunu düşünüyorsanız yorum yazmayı unutmayın. Başka bir yazıda daha görüşmek üzere, sağlıklı günler.
