MVC Nedir? Gerçek Örneklerle MVC Nedir Anlayalım

By -

MVC nedir?

MVC (Model-View-Controller), yazdığımız uygulamanın iş mantığı ile (business logic) kullanıcı arayüzünü birbirinden ayrıştıran, uygulamanın farklı amaçlara hizmet eden kısımlarının birbirine girmesini engelleyen yazılım mimarisidir.

Kodun farklı amaçlara hizmet eden yapılarını birbirinden ayırarak, kodu daha rahat geliştirilebilir ve test edilebilir (yani daha az hata çıkartma potansiyeline sahip) hale getirmiş oluruz.

Kafalar karıştı...

Kafalar karıştı…

Tam anlamadınız mı?

Daha rahat anlatabilmek için Model, View ve de Controller’ın tanımını yapalım, sonra da niye MVC’ye ihtiyaç duyduğumuzdan bahsedelim ve MVC nedir sorusu için gerçek hayattan bir örnek verelim.

 

Model

  • Uygulamada kullanılan verileri temsil eder ve verilerin işlenme mantığının saklandığı kısımdır. (Verilerin validasyonu burada yapılır)
  • Genelde verilerin veritabanı (veya XML gibi benzer bir yere) kaydedilmesi ve kayıtlı yerden alınması işlemleri yine burada olabilir. (Genelde dedim, şu an detaya girmeyeceğim. Daha sonraki yazılarda bu konuyu detaylıca inceleyeceğim.)

View

  • Basitçe, uygulamanızın kullanıcılarınızın gözüyle gördüğü kısmıdır, arayüzdür.

    MVC Nedir?

    Model-View-Controller

Controller

  • Model ve View arasında getir götür işlemlerini gerçekleştirir.
  • Kullanıcıların View üzerinden gerçekleştirdiği işlemlerle alınan veriyi Model’e taşır, Model’den aldığı veriyi View üzerinden kullanıcıya gösterir.
  • MVC yapısında ana mantık Model ve View yapısının ayrılmasıdır. Bu iki yapı arasındaki haberleşmeyi sağlayan köprüye Controller diyoruz.

 

Peki neden MVC mimarisini kullanmalıyız?

Aslında başta bundan söz etmemiz gerekirdi, ancak MVC nedir tam bilmeden MVC’nin yapısı hakkında konuşarak sebeplerini açıklamak çok anlaşılır olmayacağından bu şekilde bir sıra izlemek daha iyi oldu.

İyi de bu bilgi gerçek hayatta ne işime yarayacak?

İyi de bu bilgi gerçek hayatta ne işime yarayacak?

Sadede gelirsek, MVC sayesinde Model ve View yapısını ayrıştırmış oluyoruz.

Böylelikle yarın bir gün uygulamamızın görünümünü değiştirmek durumunda kaldığımızda “yalnızca” görünümle uğraşmamız gerekecek. İç içe geçmiş, spagetti bir kodla uğraşmak durumunda kalmış olsaydık, sadece görünümü değiştirmek isterken uygulamanın “işleyişini” de değiştirmemiz gerekecekti. (Hatta bunu yaparken işleyişi de yanlışlıkla bozabilirdik)

Ayrıca, bu ayrıştırma sayesinde Model ve View yapımızda ihtiyaç duyduğumuz parçaları, başka projelerde de tekrar kullanılabilir hale getirmiş olduk. Sonuçta, yazılım geliştirmede yegane amacımız “hatadan uzak olmak” ve “zamandan tasarruf etmek”.

Gerçek hayattan bir örnek ver de MVC nedir tam anlayalım!

Hay hay!

MVC nedir sorusunu cevaplayan, Programmers – StackExchange‘de karşılaştığım şöyle güzel bir örnekten alıntı yapabilirim:

Satranç uygulaması yaptığımızı düşünelim…

Model’de oyunun “durumu” barındırılacaktır. Oyunun durumunu değiştirecek etkiler (örneğin bir taşın hareketinin doğru olup olmadığı) veya oyunun bitip bitmediği gibi bilgiler model üzerinde yer alacaktır. (Kısaca, oyunun tüm bilgileri ve yapılacak işlemlerin validasyonu Model üzerinde barınacak)

View kısmında satranç tahtasının görünümü, yönettiğimiz piyonların şekilleri ve piyonları hareket ettirdiğimizde hangi piyonun nereye gittiğini söyleyen bildirimler yer alacaktır. Piyonların nasıl hareket ettiği, oyunun durumuyla ilgili mantıksal bilgilerin View ile hiçbir işi olmayacaktır. View sadece ve sadece görselliği barındıracaktır.

Controller ise View ve Model arasında haberleşmeyi sağlayacaktır. Örneğin, kullanıcı View’da yer alan “Yeni oyun başlat” butonuna bastığında Controller, Model’e giderek böyle bir isteğin geldiğini söyleyecektir. (Tüm bu işleri yapan Model olacaktır, Controller’ın amacı böyle bir isteğin geldiğini ve alakalı isteğin detaylarını Model’e iletmektir)

Tamam ya... Anladım şimdi!

Tamam ya… Anladım şimdi!

Peki kazancımız ne oldu?

  • Model veya View üzerinde değişiklik yapmak istediğimizde bu değişiklikler Model veya View’u artık etkilemeyecek. Yapılan bu değişiklikler Controller’ın yapısını değiştirmemize sebep verebilir ama hiç değilse değişiklik yapacağımız yeri sabit kısımlardan ayırmış olup spagetti kodu engellemiş olduk.
  • Model ya da View’u tekrar kullanabilir hale getirdik. Örneğin Model olarak RSS feed’i kullanıp View’u sabit tutarak, daha önceden oynanmış oyunları hazırladığımız View üzerinde gösterebiliriz. (Replay misali) Veya View’u değiştirip Model’i sabit tutarak oyunu hem Web sitesi üzerinden hem de Konsol uygulaması üzerinden oynanabilir hale getirebiliriz.
  • Hem View hem de Model’i iyi ayrıştırdığımız için bu yapılara Ünite testi yazmayı da kolaylaştırmış olduk.

Sanıyorum örnekle yapı aklınızda daha iyi canlandı.

Önemli noktalar

  • Controller bizim için yalnızca aracı görevi görüyor. İş mantığı Model’de, görsel mantık View’da olmalı, Controller sadece haberleşmeyi sağlamalı. Controller’a, Model’in ve/ya View’ın sorumlulukları yüklenirse MVC kullanmanın hiçbir anlamı yok.
  • Yukarıda bahsettiğimiz sebepten ötürü Fat Model, Skinny Controller yapısını kurgulamamız lazım. Algoritmayı Controller’a sıçratırsak eğer MVC kullanmamızın hiçbir kazancı kalmıyor.
  • Pek çok MVC nedir makalesi Web tabanlı projelerden örnek verse de, Desktop/Mobil uygulama geliştirirken de MVC kullanılabilir. Zira MVC bir mimari biçimdir. (Örneğin iOS geliştiriciler iPhone uygulaması geliştirirken MVC modelini kullanır)

MVC nedir konusunda hala kafanıza takılan sorular varsa lütfen sorunuzu yorum olarak bırakın. Konuşmayı/tartışmayı çok seviyoruz!

-->