VIPER tasarım paterni nedir?
Giriş
Bildiğiniz üzere Apple iOS uygulama geliştirmelerinde MVC paterni kullanıyor ve kendi örnek uygulamalarınıda bu paterne uygun bir şekilde geliştiriyor. MVC 1996 da kullanılmaya başlanan ve uygulamanın modüler hale getirmede çok başarılı olmuş bir modeldi. Microsoft da bu modeli web uygulamarında web formdan MVC paterne geçerek 2009 yılından itibaren kullanmaya başlamıştı.
iOS uygulamalarında projelerin boyutu büyüdükçe artık MVC paterni ihtiyaçları karşılamamaya başladı. Özellikle View Controller’lar binlerce satıra ulaştığında bakım yapılması oldukça güçleşti. Uygulamanın hayat döngüsüne tam uymadığı için business logic için farklı yöntemler ile -örneğin model classlarda kategori ile business layer oluşturmak gibi — uygulamanın daha modüler ve sade hale getirildi. Her ne kadar bu iyileştirmeler daha temiz bir kod yazılmasında bir sonuç vermiş olsa da yeni uygulamanın hayat döngüsüne uygun bir tasarım paternine ihtiyaç vardı. Şu an kullanımda olan MVC haricinde MVP, MVVM ve VIPER tasarım paternleri var. Bunlardan en yeni ve iOS uygulamaları için en iyi kurgulanmış olan VIPER tasarım paterni yakından inceleyelim.
VIPER mimarisi nelerden oluşur?
VIPER mimarisi adını View, Interactor, Presenter, Entity ve Router (Wireframe)’ın ilk harflerinden alıyor. Bu kavramların ne olduğuna kısaca bakalım.
View: VIPER mimarisinde view passive görevdedir ve Presenter’ın kendisine gösterilecek içeriği vermesini bekler. Hangi içeriğin gösterileceği View’e bağlıdır. Kullanıcı actionları presenter’a yönlendirir.
Interactor: Business logic işlemlerinin yapıldığı kısımdır ve uygulamanın omurgasını oluşturur. 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: 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: 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 katmanları bir evin birbirinden farklı odaları gibi düşünebiliriz. Her odanın kendine has bir işlevi vardır ve diğer odalarla bağlantı içindedir. Bu odalar birbiri ile olan bağlantılarını giriş ve çıkış işlemleri olarak yaparlar ve hangi odada hangi işlemlerin yapılacağı giriş ve çıkış protokolleri ile belirlenmiş olur. iOS uygulamalarının yaşam döngülerine göre VIPER tasarım mimarisi en uygun olanıdır. Büyük ve bakım yapılması zor olan projelerde başarılı bir şekilde uygulanabilir. Bütün ekibin bu mimariyi iyice özümsemiş olması çok önemlidir. Ekibe yeni katılacak elemanlarda yine önce bu paterni öğrenmeleri gerekiyor. Bunu sağlamak önemli çünkü iyi düzenlenmiş bir mimariye uymayan kodlar sonradan içinde çıkılmaz bir karmaşıklığa neden olabiliyor. Bunu bu paternin bir dezavantajı olarak görebiliriz. Yine ayni şekilde küçük projelerde uygulanmasının da kodda karmaşıklığı biraz daha artırdığınıda söylemeden geçmeyelim.
VIPER paterni diğer patenlerden farklı olarak iOS hayat döngüsüne uygun bütün mimariyi içeren çok iyi tasarlanmış bir paterndir. Geliştiricilere çok temiz bir mimari sunar. Herhangi bir hata bulunduğunda ilgili katmanda düzeltilmesi kolaylıkla yapılabilir. Ayrıca bir çok geliştirici farklı katmanlarda birebirinden bağımsız çalışma imkânını bulur.
VIPER mimarisinin avantajları
1. Kodun test edilebilirliğini ve tekrar kullanılabilirliğini sağlar.
2. Rollerine göre uygulamayı komponentlere böler ve ilgili kodların birbirinden bağımsız ayrılmasını sağlar.
3. Yeni özelliklerin eklenmesini kolaylaştırır.
4. UI logic Business logicden ayrı yazıldığı için otomated testlerin yazımını kolaylaştırır.
VIPER mimarisinin dezavantajları
1. Küçük projelerde karmaşıklığı artırır.
2. Tüm ekibin paterni iyi bilmesi ve ona uygun kod yazması gerekir.
3. Projeye yeni başlayanlarda paterne uygun kod yazması için öğrenme süreci gerektirir.
Bu paterni iyi kavrayabilmek için mutlaka örnek bir proje yapmanız gerekiyor Aşağıda daha önce bu paterne uygun olarak geliştirdiğim projeyi bulabilirsiniz.
