Android Yazılım Mimarileri

Merhabalar, bu yazımda Android yazılım mimarisi nedir, neden bir mimari yapıya ihtiyaç duyarız, Clean Architecture nedir gibi sorulara yanıt arayacağım ve en yaygın kullanılan mimari desenlerin katmanları nelerdir bunlardan bahsedeceğim.

Öncelikle, “Yazılım mimarisi nedir?” bu konuya değinelim.

Yazılım mimarisi nedir?

Yazılım mimarileri, yazılım projelerinde sürekli karşılaşılan benzer sorunlardan yola çıkarak, Code Optimization’ ını en iyi şekilde kurgulayabilmemize imkan tanıyan yapılardır.

Yazılımları iki bölüme ayırabiliriz. Bunların ilki Graphical User Interface (GUI) yani kullanıcıların gördüğü ve kullandığı görünüm ara yüzüdür. İkincisi ise bu ara yüzün kontrol mekanizması ve planlayıcısı olan bir mantık ünitesidir. Yazılım mimarisi de tam olarak bu iki kısmın birbirinden etkilenmemesi için görünüm ara yüzünü, mantık ünitesinden ayırmaya yarar.

Yazılım geliştirme süreci karmaşık bir süreçtir. Bu süreçte dağılmak istemiyorsanız bir yazılım mimarisi oluşturmalısınız. Yazılım mimarisine ihtiyaç duymamızın en önemli sebeplerinden biri de sistemin karmaşıklığını yönetmek ve bütünlüğünü korumak için pratik bir yapı sunmasıdır.

Neden bir mimari yapıya ihtiyaç duyarız?

Bir yazılım mimarisi kullanmak size iyi kod yazmaktan ziyade projeyi iyi yönetme ve geliştirme avantajı getirir. Peki neden yazılım mimarisine ihtiyaç duyarız?

• Teste dayalı uygulama geliştirmeyi kolaylaştırır.
• Yazma ve okuma için kodları basitleştirir.
• Katmanlı yapısı sayesinde karışıklığı engeller.
• Uygulama güvenliği konusunda büyük artıları vardır.
• Dışarıdan ulaşan herkese “View” kısmı gösterilir.
• Büyük projelerde, projenin denetimini ve yönetimini kolaylaştırır.
• “Front-end” ve “Back-end” kodları birbirinden bağımsız bir şekilde değiştirilebilir.

Clean Architecture nedir?

Onion Architecture gibi birçok parça parça yazılmış desenlerin son hali olarak düşünebiliriz.

Bir proje, en basit ihtiyacından başlayarak ürüne dönüşeceği kısmına kadar bölünmelidir.

Projenin iş yapan katmanları, modelleri ve bağımlıkları iç içe olmamalı daima proje katmanları birbirinden bağımsız çalışabilmelidirler.

Bu kadar parçalama bize bağımsızlık getirdiği için daha kolay Unit Test yazmamıza olanak sağlar.

En yaygın kullanılan beş mimari desenden biraz bahsedelim.

MVC

MVC, Model, View ve Controller kelimelerinin baş harflerinden oluşan bir yazılım mimari desenidir.

MVC deseni, üç katmandan oluşmaktadır ve katmanları birbirinden bağımsız olarak çalışır. Bu sebeple projelerin yönetiminin ve kontrolünün daha rahat sağlayabilir. MVC ile geliştirilen projelerde projenin detaylarına göre birçok kişi eş zamanlı olarak kolaylıkla çalışır.

• Model

Model, MVC’de projenin iş mantığının (Business Logic) oluşturulduğu bölümdür. İş mantığıyla beraber doğrulama (validation) ve veri erişim (data access) işlemleri de bu bölümde gerçekleştirilir. Model tek katmandan oluşabileceği gibi kendi içinde birden fazla katmandan da oluşabilir. İç yapılandırma projenin büyüklüğü ile yazılım geliştiricinin planlamasına kalmış bir durumdur. Eğer proje büyük çaplı ise modeli birden çok katmana ayırmak projenin yönetimi açısından faydalı olacaktır.

• View

View, MVC’de projenin arayüzlerinin oluşturulduğu bölümdür. Bu bölümde projenin kullanıcılara sunulacak olan dosyaları yer alır. Projenin geliştirildiği yazılım dillerine göre dosya uzantıları da değişebilir. View’ın bir görevi de, kullanıcılardan alınan istekleri controller’a iletmektir.

• Controller

Controller, MVC’de projenin iç süreçlerini kontrol eden bölümdür. Bu bölümde View ile Model arasındaki bağlantı kurulur. Kullanıcılardan gelen istekler (request) Controller’larda değerlendirilir, isteğin detayına göre hangi işlemlerin yapılacağı ve kullanıcıya hangi View’ın döneceği (response) belirtilir.

MVVM

MVVM, Model, View ve ViewModel kelimelerinin baş harflerinden oluşan ve “sorumlulukların ayrıştırılması” esasına göre geliştirilmesi temeline dayanan bir yazılım mimari desenidir. MVC deki Controller yerini MVVM de ViewModel almaktadır.

• Model

Veri tabanından, web servislerinden ya da herhangi bir veri kaynağından gelen verilerimizi temsil etmek için kullanılan “Entity” sınıflarından oluşmaktadır. Ayrıca veri tutarlığını ve doğruluğunu kontrol eden iş kuralları da burada yer almaktadır.

• View

Bu kısım verilerimizi son kullanıcılara aktardığımız görsel ara yüzdür. Son kullanıcı ile uygulama arasında bir köprü görevi görür.

• ViewModel

ViewModel ise görsel arayüz ile model arasında köprü görevi görür, yani Model’i View’a bağlayan yapıdır. View ile Model arasında doğrudan bir etkileşim yoktur. View, ilgili işlemleri ViewModel üzerinden yapar.

MVP

MVP, MVC’ den evrilmiş bir mimaridir ve Controller’ın yerine Prenseter gelir. Model, View ve Presenter dan oluşur.

• Model

View de görüntülenecek veya başka bir şekilde davranacak verilerin işlendiği kısımdır. Presenter’ın ihtiyaç duyduğu bilgileri sağlar. İş mantığı bu kısımda ele alınır.

• View

Verilerin görüntülendiği ve işlem yapmak için kullanıcı ile etkileşime geçilen kısımdır. MVP tasarım deseninde iki çeşit View kullanılabilir. Supervising Controller View, Passive View.

• Presenter

Model ile View arasındaki bağlantıyı sağlayan kısımdır. Verileri modelden alır ve UI mantığını uygular. Ayrıca View’dan gelen kullanıcı etkileşimlerine tepki verir.

VIPER

VIPER, adını View, Interactor, Presenter, Entity ve Router ’ın ilk harflerinden alan bir yazılım mimarisidir.

• View

Her ikisi de kullanıcı için görüntüleri ve kullanıcı etkileşimini algılar. Kendi başına pek bir şey yapmaz. Sorumluluğu olayları Presenter modülüne iletmek ve UI öğelerini göstermektir. Presenter, View modülünün iletişim kurduğu tek modüldür.

• Interactor

Interactor, Business Logic işlemlerinin yapıldığı kısımdır ve uygulamanın omurgasını oluşturur. Verileri alır ve depolar. Örneğin uygulamamızda API çağrımı yaparken genellikle bu katmandan yaparız. Bu katmanda yapılan işlemler tamamen UI dan bağımsız olmalıdır.

• Presenter

Presenter esas olarak view ile ilgili Logic’i içeren kodu içerir. User işlemlerine göre Interactor’dan data alır ve bunu gösterilmek üzere View katmanına iletir. View ile Interactor arasında bir köprü görevi görür. Bu katmanda view ile ilgili veya uygulamanın Business kurallarıyla ilgili kod bulunmamalıdır.

• Entity

Entity, VIPER içerisindeki en küçük elementtir. Interactor tarafından kullanılan model nesnelerini içerir. Entity’lerin sadece Interactor tarafından kullanılması çok önemlidir. Interactor asla presenter layer’a entity modellerini göndermez.

• Router

Router, hangi ekranların ne zaman gösterileceğini belirlendiği uygulama geçiş akışın bulunduğu katmandır. Ayrıca geçiş animasyonlarda bu katmanda bulunur. Router yalnızca Presenter ile iletişime geçer.

Bu yazımda size yazılım mimarisinin tanımıyla birlikte kullanılma amacına değindim. Yazılım mimarileri elbette bunlarla sınırlı değil ama en sık kullanılan beş ana Android yazılım mimarisi hakkında kısa bir anlatımım oldu.

Vakit ayırdığınız için teşekkürler.