Bundan birkaç yıl önce iOS’a çıkan uygulamalar oldukça ufaktı. Çoğu 10 ekrandan daha ötesine gitmiyordu. Kod yapısı ufak, storyboard mükemmel çalışıyordu. Uygulama mimarisi açısından MVC gayet iyi şekilde uygulanıyordu.

Günümüzde teknolojik gelişmeler ve marketin aşırı büyümesi ile  karşı karşıyayız. Diğer bir açından artık geliştirilen uygulamalar oldukça büyük ve karmaşık bir yapıya sahip. Bu nedenle MVC ile uygulama geliştirmek 30-40 ekranlı uygulamalar için karmaşıklığında ötesine geçmiş durumda.

Clean Swift, bu karmaşıklığa bir düzen getirmek için geliştirilen bir mimari. Aslında mimariden farklı olarak Clean Architecture’e uygun komponentler oluşturmamıza yarayan bir araç olarak düşünebiliriz.

Standart bir MVC projesinde controller’lar, model’ler ve view’ler kendine gruplanarak organize edilir. Clean Swift’te bu ekranlara göre organize ediliyor.

Örnek ile açıklamak gerekirse; bir ekran için 6 adet komponent gerekiyor.

• Model
• Router
• Worker
• Interactor
• Presenter
• Configrator

Bunların ne olduğuna birazdan değineceğim.

İletişim

Standart bir MVC projesinde M yani model kullanıcıya gösterilecek verilerin oluşturulduğu katmandır. V yani view kullanıcının gördüğü ekran olmakla birlikte, Model ve View arasındaki iletişimi Controller yapar.

Kavramsal olarak çalışma şekli bu halde olsada uygulamaya geçtiğimizde Controller ve Model iç içe geçmeye başlar. Kısa sürede debug etmesi oldukça zorlaşır. Yeni özellik eklemek veya çıkarmak istediğinizde satırlarca kodu gözden geçirmek gibi bir problem karşınıza çıkmaya başlar.

Clean Swift ile bu iletişim protokoller ile yapılır. Her komponent kendine has input ve output protokollerine sahiptir.

İletişim şu şekilde gerçekleşir.

Worker > Interactor > Presenter > ViewController

Komponentleri anlatarak bu akışa daha derinlemesine bakalım.

Model

Gösterilecek ekrana ait ve API’lerle yapılacak işlemler de dahil olmak üzere tüm veri modelleri burada tutulur.

Temel olarak 3 struct’dan oluşan bir struct tipidir.

import UIKit


struct TestModel{


struct Fetch {


struct Request
{


var itemId = 0
var keyword: String?
var count: String?

}
struct Response
{


var testObj: Any?
var isError: Bool
var message: String?


}
struct ViewModel
{

var name: String?
var date: String?
var isError: Bool
var message: String?


}


}


}

Verdiğim örnekte Request, API’ye istek göndermede kullanılacak parametreleri oluşturur. Response, API’den gelen yanıttır. ViewModel ise UI’da gösterilecek olacak dataları saklar.

Router

Router basit bir komponent. Gerekli olduğu durumlarda ViewController’lar arası veri alışverişini yapar. Ayrıca ViewController’lar arası segue’leri (geçişleri) de sağlar.

Worker

Bu komponent bütün API/CoreData request ve response’larını yönetir. Modelde oluşturduğumuz Response struct’ı, Interactor’a göndermek üzere oluşan datayı alır. Ayrıca success ve error event’lerini de sürdürür. Böylece Interactor verilere ne olduğuna dair fikir sahibi olur.

Interactor

Interactor’un görevi Worker ve Presenter arası iletişimdir. İlk olarak ViewController’e bağlanıp Worker için gerekli Request parametrelerinin gönderilmesini sağlar. Worker’a göndermeden önce validation’ı yapar. Eğer problem yoksa Worker üzerinden gelen response, Interactor üzerinden Presenter’a iletilir.

Presenter

Interactor’den gelen data artık ViewModel’ dönüşmek için hazır. Presenter’in görevi bu işlemi sağlamaktır.

Configrator

Bunu superclass olarak da düşünebiliriz. Görevi basit ama önemli. Yukarıda bahsettiğim tüm komponentleri hazırlamaktır. Singleton tipindedir.

ViewController

Komponentlerin görevinden bahsettikten sonra sırada ViewController var. ViewController, yukarıdaki komponentlerin bir kesişim noktasıdır. Gerektiğinde Interactor ile konuşur, Presenter’dan response’ı alır. Ayrıca ekran geçişleri için Router ile çalışır.

Özetlemek gerekirse, MVC hala geçerli. Dilerseniz MVC’de devam edip yazının başında bahsettiğim sorunlara çözüm arayabilirsiniz. Clean Swift’i denediğinizde ilk başta daha fazla kod yazmak ve projenize daha fazla dosya eklemek “yanlış mı yapıyorum?” sorusunu aklınıza getirebilir. Ama geliştirmenin ileri safhalarında ve sonrasında bunun faydasını göreceğinizi düşünüyorum.