Daha önce Android architecture component hakkında genel bir bilgi toplamaya çalışmıştım. Aslında belki de öncesinde bugünlere nasıl gelindiğiyle ilgili biraz düşünmekte, konuşmakta fayda var.
Android’in tarihi çok eski olmamakla beraber aslında ilk yazmaya başladığımız, henüz herhangi bir library vs kullanmadığımız dönemde her birimiz kendi çözümlerimizi geliştiriyorduk ve paylaşıyorduk. Çoğumuz MVC(Model View Controller) kullanarak başladık. Bu yüzden de MVC’nin nasıl bir pattern olduğunu anlatarak başlamak istiyorum 🙂
MVC‘de; Model data’nın, state’in ve business logic’in tutulduğu yerdir. Controller ve View’e bağlı değildir, böylece tekrar tekrar kullanılabilir. View, ui’ın render edildiği parçadır. Herhangi bir akla sahip değildir. Controller ise view ve model arasında bağlantıyı kuran parçacıktır. Örneğin bir butona tıklandığında ne aksiyon alınacağı bilgisi Controller’dadır. Burada tıklandıldığı bilgisi veren View, yapılacak işi içeren kısım ise Model’dir. Android’de ise Activity ve Fragment’ler Controller’a denk gelir.
MVC pattern’ı kullandığımızda business logic Model’de yer aldığı için testable bir mimarimiz olmuş olur ve kolayca Model için unit test yazabiliriz. Gerçek şu ki zamanla kod yavaş yavaş Controller’a taşınmaya başlar ve bu da kodun bakımını zorlaştırır. Bunun dışında her ne kadar Model için rahatça unit test yazılabiliyor olsa da bu Controller için o kadar kolay olmayacaktır. Çünkü Controller’lar Android API’larına çok bağlıdır. Ayrıca View’in de bir extention’ı gibi olduğu için view’de birşey değiştirdiğimizde gidip Controller’da da değiştirmemiz gerekir ki bu da modülerlik ve esnekliğin kırılmasına neden olur.
MVP(Model, View, Presenter)’nin en büyük farklı controller’ı parçalıyor olması. Böylece view/activity doğal bağına devam ederken activity, controller sorumluluklarından arınmış olur. Model MVC’yle aynı. View’de fark olarak bu sefer Activity ve fragment de view’dedir. Ancak herhangi bir logic implement edilmez. Burada hem view hem de presenter birer interface’i implement ediyor. Activity hem view’i hem de presenter’ı create eder. Presenter kullanıcıdan gelen inputu view’i aracılığıyla alır.
Presenter, MVC’deki controller’dır ancak bu sefer view’e bir bağımlılığı yoktur. Avantajı MVC’de view’e bağımlılığından dolayı Controller’a unit test yazamıyorduk. Burada View mock’lanarak yazılabilir. MVP küçük projelerde avantajlı olmakla beraber büyük projelerde çok fazla class olmasına sebep olabilir, zamanla presenter classlar şişebilir.
MVVM(Model, View, View-Model), View’in değişikliklere yanıt verebileceği event-based bir mimari kurmak istersek de karşımıza MVVM çıkacak. Model, MVC’yle aynı. View, viewmodelden sağlanan observable variable’ları bağlar. ViewModel, Model’i wrapleyip View tarafından ihtiyaç duyulan observable datanın sağlanmasından sorumlu.
Yani aslında yine business logic’den model sorumlu. Data değiştiğinde ViewModel bundan haberdar oldu ve View’e haber verdi. View’de ui’ı update etti diyebiliriz basitçe.
Artık view’e hiç bir bağımlılık kalmadığından mocklanmadan da artık test yazılabilir durumda. Diğer modellere göre biraz daha karmaşık olması ise dezavantajı diyebiliriz.
Referanslar:
- https://news.realm.io/news/eric-maxwell-mvc-mvp-and-mvvm-on-android/
- https://medium.com/@ankit.sinhal/mvc-mvp-and-mvvm-design-pattern-6e169567bbad
- https://medium.com/upday-devs/android-architecture-patterns-part-1-model-view-controller-3baecef5f2b6
- https://upday.github.io/blog/model-view-presenter/
- https://upday.github.io/blog/model-view-viewmodel/
- https://developer.android.com/topic/libraries/data-binding/index.html
Elif Boncuk's Blog 
Leave a Reply