Modern uygulama geli\u015ftirme s\u00fcre\u00e7lerinde karma\u015f\u0131kl\u0131\u011f\u0131 y\u00f6netmek ve s\u00fcrd\u00fcr\u00fclebilir kod yap\u0131lar\u0131 olu\u015fturmak hayati \u00f6nem ta\u015f\u0131r. MVC, MVP, MVVM, MVVM-C ve VIPER gibi mimari kal\u0131plar, yaz\u0131l\u0131m bile\u015fenlerini ayr\u0131\u015ft\u0131rarak geli\u015ftiricilere bu zorluklar\u0131n \u00fcstesinden gelme imkan\u0131 sunar. Bu makalede, her bir kal\u0131b\u0131n temel prensiplerini, avantajlar\u0131n\u0131, dezavantajlar\u0131n\u0131 ve ger\u00e7ek d\u00fcnya senaryolar\u0131ndaki kullan\u0131mlar\u0131n\u0131 detayl\u0131ca inceleyece\u011fiz.<\/p>\n
G\u00fcn\u00fcm\u00fcz\u00fcn dijital d\u00fcnyas\u0131nda, ister bir mobil uygulama isterse b\u00fcy\u00fck bir web platformu geli\u015ftiriyor olal\u0131m, projenin boyutu ve karma\u015f\u0131kl\u0131\u011f\u0131 h\u0131zla artmaktad\u0131r. Kullan\u0131c\u0131 aray\u00fcz\u00fc (UI) ve i\u015f mant\u0131\u011f\u0131n\u0131n birbiriyle i\u00e7 i\u00e7e ge\u00e7ti\u011fi durumlarda, kodun okunabilirli\u011fi, bak\u0131m\u0131 ve test edilebilirli\u011fi ciddi \u015fekilde zorla\u015f\u0131r. \u0130\u015fte tam da bu noktada, yaz\u0131l\u0131m mimarisi (software architecture) kal\u0131plar\u0131 devreye girer. Bu kal\u0131plar, geli\u015ftiricilere kodlar\u0131n\u0131 d\u00fczenli, mod\u00fcler ve y\u00f6netilebilir bir \u015fekilde yap\u0131land\u0131rmalar\u0131 i\u00e7in yol g\u00f6steren \u00f6nceden tan\u0131mlanm\u0131\u015f \u00e7\u00f6z\u00fcmler sunar.<\/p>\n
Peki, bu mimari kal\u0131plara neden bu kadar \u00e7ok ihtiya\u00e7 duyuyoruz? Temel neden, “sorumluluklar\u0131n ayr\u0131\u015ft\u0131r\u0131lmas\u0131” (separation of concerns) prensibidir. Bir uygulaman\u0131n farkl\u0131 b\u00f6l\u00fcmlerinin (\u00f6rne\u011fin, veri y\u00f6netimi, kullan\u0131c\u0131 aray\u00fcz\u00fc g\u00f6sterimi, i\u015f mant\u0131\u011f\u0131) kendi sorumluluk alanlar\u0131na sahip olmas\u0131, birinde yap\u0131lan de\u011fi\u015fikli\u011fin di\u011ferini minimum d\u00fczeyde etkilemesini sa\u011flar. Bu sayede, bir hata ay\u0131klama (debugging) s\u00fcreci \u00e7ok daha kolay hale gelir, yeni \u00f6zellikler eklemek daha az riskli olur ve farkl\u0131 geli\u015ftiricilerin ayn\u0131 proje \u00fczerinde e\u015f zamanl\u0131 \u00e7al\u0131\u015fmas\u0131 m\u00fcmk\u00fcn olur.<\/p>\n
Ayr\u0131ca, iyi bir mimari kal\u0131p se\u00e7imi, uygulaman\u0131n ya\u015fam d\u00f6ng\u00fcs\u00fc boyunca kar\u015f\u0131la\u015fabilece\u011fi zorluklara kar\u015f\u0131 diren\u00e7li olmas\u0131n\u0131 sa\u011flar. \u00d6rne\u011fin, bir uygulaman\u0131n kullan\u0131c\u0131 aray\u00fcz\u00fc teknolojisi de\u011fi\u015fti\u011finde, i\u015f mant\u0131\u011f\u0131n\u0131n b\u00fcy\u00fck \u00f6l\u00e7\u00fcde yeniden yaz\u0131lmas\u0131 gerekmez. Benzer \u015fekilde, uygulaman\u0131n test edilebilirli\u011fi (testability) artar. Her bir bile\u015fen ba\u011f\u0131ms\u0131z olarak test edilebildi\u011fi i\u00e7in, uygulaman\u0131n genel kalitesi y\u00fckselir ve hatalar\u0131n \u00fcretim ortam\u0131na ula\u015fma olas\u0131l\u0131\u011f\u0131 azal\u0131r. Bu da uzun vadede hem zaman hem de maliyet tasarrufu anlam\u0131na gelir. Geli\u015ftiricilerin bu kal\u0131plar\u0131 derinlemesine anlamas\u0131, hangi projenin hangi mimariyi gerektirdi\u011fini daha iyi anlamalar\u0131na ve dolay\u0131s\u0131yla daha sa\u011flam, esnek ve s\u00fcrd\u00fcr\u00fclebilir yaz\u0131l\u0131mlar geli\u015ftirmelerine olanak tan\u0131r.<\/p>\n
Model-View-Controller (MVC), 1970’lerin sonunda ortaya \u00e7\u0131kan ve Smalltalk gibi dillerde pop\u00fclerle\u015fen, yaz\u0131l\u0131m mimarisinin temel ta\u015flar\u0131ndan biridir. Ad\u0131ndan da anla\u015f\u0131laca\u011f\u0131 gibi, uygulamay\u0131 \u00fc\u00e7 ana bile\u015fene ay\u0131r\u0131r:<\/p>\n
MVC’nin temel amac\u0131, sorumluluklar\u0131 net bir \u015fekilde ay\u0131rarak kodun daha y\u00f6netilebilir ve yeniden kullan\u0131labilir olmas\u0131n\u0131 sa\u011flamakt\u0131r. \u00d6rne\u011fin, bir e-ticaret uygulamas\u0131nda \u00fcr\u00fcn listeleme ekran\u0131n\u0131 d\u00fc\u015f\u00fcnelim. \u00dcr\u00fcn verileri Bir kod \u00f6rne\u011fiyle Controller’\u0131n nas\u0131l \u00e7al\u0131\u015ft\u0131\u011f\u0131n\u0131 g\u00f6relim:<\/p>\n MVC’nin avantajlar\u0131 aras\u0131nda kodun mod\u00fclerli\u011fi, farkl\u0131 geli\u015ftiricilerin ayn\u0131 anda farkl\u0131 bile\u015fenler \u00fczerinde \u00e7al\u0131\u015fabilmesi ve test edilebilirli\u011fin artmas\u0131 say\u0131labilir. Ancak dezavantajlar\u0131 da vard\u0131r; \u00f6zellikle b\u00fcy\u00fck ve karma\u015f\u0131k View’larda Controller’lar \u015fi\u015febilir (Fat Controller problemi) ve View ile Controller aras\u0131ndaki s\u0131k\u0131 ba\u011f, test yazmay\u0131 zorla\u015ft\u0131rabilir. Ayr\u0131ca, View’\u0131n Model’e do\u011frudan eri\u015febilmesi, sorumluluklar\u0131n tam olarak ayr\u0131\u015fmamas\u0131na neden olabilir.<\/p>\n Model-View-Presenter (MVP), MVC’nin “Fat Controller” ve test edilebilirlik sorunlar\u0131na bir yan\u0131t olarak ortaya \u00e7\u0131km\u0131\u015ft\u0131r. \u00d6zellikle Windows Forms ve Android gibi platformlarda pop\u00fclerlik kazanm\u0131\u015ft\u0131r. MVP’de de \u00fc\u00e7 ana bile\u015fen bulunur:<\/p>\n MVP’de View, bir aray\u00fcz (interface) uygular ve Presenter bu aray\u00fcz \u00fczerinden View ile ileti\u015fim kurar. Bu, Presenter’\u0131n ger\u00e7ek View’dan ba\u011f\u0131ms\u0131z olarak test edilmesine olanak tan\u0131r. \u00d6rne\u011fin, bir giri\u015f ekran\u0131nda, kullan\u0131c\u0131 ad\u0131 ve \u015fifrenin do\u011frulanmas\u0131 gibi t\u00fcm i\u015f mant\u0131\u011f\u0131 Presenter i\u00e7inde yer al\u0131r. View sadece bu bilgileri Presenter’a iletir ve Presenter’\u0131n “giri\u015f ba\u015far\u0131l\u0131”, “giri\u015f ba\u015far\u0131s\u0131z” gibi komutlar\u0131n\u0131 ekranda g\u00f6sterir.<\/p>\n MVP’nin en b\u00fcy\u00fck avantaj\u0131, Presenter’\u0131n tamamen test edilebilir olmas\u0131d\u0131r, \u00e7\u00fcnk\u00fc View bir aray\u00fczle temsil edildi\u011fi i\u00e7in kolayca sahte (mock) bir View nesnesi olu\u015fturulabilir. Bu, birim testlerinin (unit tests) yaz\u0131lmas\u0131n\u0131 olduk\u00e7a kolayla\u015ft\u0131r\u0131r. Ayr\u0131ca, View’\u0131n pasif olmas\u0131, View’\u0131n karma\u015f\u0131kl\u0131\u011f\u0131n\u0131 azalt\u0131r ve sorumluluklar\u0131 daha net bir \u015fekilde ay\u0131r\u0131r. Ancak, View ve Presenter aras\u0131nda birebir bir ili\u015fki olmas\u0131, \u00f6zellikle \u00e7ok say\u0131da View ve Presenter oldu\u011funda kod tekrar\u0131na yol a\u00e7abilir. Ayr\u0131ca, View’\u0131n her eylemi Presenter’a bildirmesi ve her g\u00fcncelleme i\u00e7in Presenter’dan talimat beklemesi, baz\u0131 durumlarda biraz fazla “el eme\u011fi” gerektirebilir.<\/p>\n Model-View-ViewModel (MVVM), \u00f6zellikle veri ba\u011flama (data binding) yetenekleri g\u00fc\u00e7l\u00fc olan UI \u00e7er\u00e7eveleri (frameworks) ile birlikte kullan\u0131lmak \u00fczere tasarlanm\u0131\u015ft\u0131r (\u00f6rne\u011fin, WPF, Silverlight, Android Jetpack Compose, SwiftUI, React). MVVM’de de \u00fc\u00e7 ana bile\u015fen bulunur:<\/p>\n MVVM’nin en b\u00fcy\u00fck g\u00fcc\u00fc veri ba\u011flamad\u0131r. Bu sayede, View ve ViewModel aras\u0131ndaki ileti\u015fim b\u00fcy\u00fck \u00f6l\u00e7\u00fcde otomatize edilir. \u00d6rne\u011fin, bir kullan\u0131c\u0131 bir metin kutusuna yaz\u0131 yazd\u0131\u011f\u0131nda, bu veri otomatik olarak ViewModel’deki ilgili \u00f6zelli\u011fe ba\u011flan\u0131r. ViewModel bu veriyi i\u015fler (\u00f6rne\u011fin, bir arama sorgusu ba\u015flat\u0131r) ve sonu\u00e7lar\u0131 g\u00fcnceller. View, ViewModel’deki sonu\u00e7 \u00f6zelli\u011fi de\u011fi\u015fti\u011finde otomatik olarak kendini g\u00fcnceller. Bu “iki y\u00f6nl\u00fc veri ba\u011flama” (two-way data binding) geli\u015ftirme s\u00fcrecini h\u0131zland\u0131r\u0131r ve kod miktar\u0131n\u0131 azalt\u0131r.<\/p>\n Bir ViewModel \u00f6rne\u011fi:<\/p>\n MVVM’nin avantajlar\u0131 aras\u0131nda y\u00fcksek test edilebilirlik (ViewModel tamamen ba\u011f\u0131ms\u0131zd\u0131r), View ve ViewModel aras\u0131nda gev\u015fek ba\u011f (loose coupling), geli\u015ftirme h\u0131z\u0131nda art\u0131\u015f ve tasar\u0131mc\u0131lar ile geli\u015ftiricilerin daha paralel \u00e7al\u0131\u015fabilmesi say\u0131labilir. Ancak, veri ba\u011flaman\u0131n karma\u015f\u0131kl\u0131\u011f\u0131 ve performans \u00fczerindeki potansiyel etkisi, \u00f6zellikle b\u00fcy\u00fck ve karma\u015f\u0131k View’larda dikkat edilmesi gereken noktalard\u0131r. Ayr\u0131ca, veri ba\u011flama mekanizmalar\u0131n\u0131 desteklemeyen platformlarda MVVM’nin uygulanmas\u0131 zor olabilir.<\/p>\n MVVM-C, Model-View-ViewModel-Coordinator’\u0131n k\u0131saltmas\u0131d\u0131r. Ad\u0131ndan da anla\u015f\u0131laca\u011f\u0131 gibi, MVVM kal\u0131b\u0131na ek olarak bir “Coordinator” (Koordinat\u00f6r) bile\u015feni ekler. MVVM kal\u0131b\u0131n\u0131n en b\u00fcy\u00fck zay\u0131fl\u0131klar\u0131ndan biri, ViewModel’lerin navigasyon mant\u0131\u011f\u0131n\u0131 (hangi ekran\u0131n ne zaman g\u00f6sterilece\u011fi, bir ak\u0131\u015f\u0131n nas\u0131l y\u00f6netilece\u011fi) i\u00e7ermeye ba\u015flamas\u0131d\u0131r. Bu durum, ViewModel’leri \u015fi\u015firir ve test edilmesini zorla\u015ft\u0131r\u0131r, \u00e7\u00fcnk\u00fc navigasyon genellikle UI bile\u015fenlerine ba\u011f\u0131ml\u0131d\u0131r.<\/p>\n Coordinator’\u0131n temel g\u00f6revi, navigasyon ak\u0131\u015f\u0131n\u0131 ve View\/ViewModel olu\u015fturma sorumlulu\u011funu \u00fcstlenmektir. Bir Coordinator:<\/p>\n MVVM-C ile ViewModel’ler art\u0131k navigasyon hakk\u0131nda bilgi sahibi olmak zorunda kalmaz. Bir ViewModel bir eylemi tamamlad\u0131\u011f\u0131nda (\u00f6rne\u011fin, bir formu doldurdu\u011funda), bu durumu Coordinator’a bildirir ve Coordinator, bir sonraki ad\u0131m\u0131 (ba\u015fka bir ekrana ge\u00e7mek, bir pop-up g\u00f6stermek vb.) tetikler. Bu sayede ViewModel’ler sadece i\u015f mant\u0131\u011f\u0131na odaklanabilir ve daha test edilebilir hale gelir.<\/p>\n \u00d6rne\u011fin, bir bankac\u0131l\u0131k uygulamas\u0131nda, para transferi yapma ak\u0131\u015f\u0131n\u0131 d\u00fc\u015f\u00fcnelim. \u0130lk ekranda al\u0131c\u0131 bilgileri girilir, ikinci ekranda miktar, \u00fc\u00e7\u00fcnc\u00fc ekranda onay. Her ekran\u0131n kendi ViewModel’i olabilir. Bu ak\u0131\u015f\u0131 y\u00f6neten bir Basit bir Coordinator yap\u0131s\u0131:<\/p>\n MVVM-C’nin avantajlar\u0131, ViewModel’lerin daha odakl\u0131 ve test edilebilir olmas\u0131, navigasyon mant\u0131\u011f\u0131n\u0131n merkezile\u015ftirilmesi ve uygulama ak\u0131\u015flar\u0131n\u0131n mod\u00fcler hale gelmesidir. Dezavantaj\u0131 ise, \u00f6zellikle k\u00fc\u00e7\u00fck projelerde ek bir soyutlama katman\u0131 (abstraction layer) getirmesi ve ba\u015flang\u0131\u00e7ta \u00f6\u011frenme e\u011frisinin olmas\u0131d\u0131r. Ancak, karma\u015f\u0131k navigasyon gerektiren b\u00fcy\u00fck uygulamalar i\u00e7in bu maliyet genellikle faydalar\u0131na de\u011ferdir.<\/p>\n VIPER, View, Interactor, Presenter, Entity ve Router kelimelerinin ba\u015f harflerinden olu\u015fan, genellikle iOS uygulamalar\u0131nda kullan\u0131lan olduk\u00e7a kat\u0131 ve kapsaml\u0131 bir mimari kal\u0131pt\u0131r. Her bir bile\u015fenin tek bir sorumlulu\u011fu (Single Responsibility Principle) olmas\u0131n\u0131 hedefler ve bu sayede maksimum ayr\u0131\u015ft\u0131rma ve test edilebilirli\u011fi sa\u011flar. VIPER, b\u00fcy\u00fck ve uzun \u00f6m\u00fcrl\u00fc projeler i\u00e7in tasarlanm\u0131\u015ft\u0131r.<\/p>\n VIPER’daki bile\u015fenler ve sorumluluklar\u0131:<\/p>\n VIPER’da her bir ekran (veya mod\u00fcl), kendi VIPER bile\u015fen setine sahiptir. Bu, her mod\u00fcl\u00fcn ba\u011f\u0131ms\u0131z olarak geli\u015ftirilebilece\u011fi ve test edilebilece\u011fi anlam\u0131na gelir. \u00d6rne\u011fin, bir haber uygulamas\u0131nda “Haber Listesi” ekran\u0131 bir VIPER mod\u00fcl\u00fc, “Haber Detay\u0131” ekran\u0131 ba\u015fka bir VIPER mod\u00fcl\u00fc olabilir. Haber Listesi Presenter’\u0131, Haber Listesi Interactor’\u0131na haberleri getirmesini s\u00f6yler, Interactor veri servisinden haber Entity’lerini al\u0131r, Presenter bu Entity’leri View’\u0131n g\u00f6sterece\u011fi formata d\u00f6n\u00fc\u015ft\u00fcr\u00fcr ve View’a sunar. Kullan\u0131c\u0131 bir habere t\u0131klad\u0131\u011f\u0131nda, Presenter Router’a Haber Detay\u0131 ekran\u0131na gitmesini s\u00f6yler.<\/p>\n VIPER’\u0131n en b\u00fcy\u00fck avantaj\u0131, kat\u0131 ayr\u0131\u015ft\u0131rma sayesinde elde edilen y\u00fcksek test edilebilirlik, mod\u00fclerlik ve \u00f6l\u00e7eklenebilirliktir. B\u00fcy\u00fck tak\u0131mlar i\u00e7in idealdir, \u00e7\u00fcnk\u00fc her geli\u015ftirici belirli bir bile\u015fen \u00fczerinde odaklanabilir. Ancak, bu kat\u0131l\u0131k ve ayr\u0131\u015ft\u0131rma, \u00f6nemli miktarda “boilerplate” (kal\u0131p kod) olu\u015fturur. Her yeni ekran i\u00e7in birden fazla dosya ve aray\u00fcz tan\u0131mlanmas\u0131 gerekir, bu da ba\u015flang\u0131\u00e7ta geli\u015ftirme h\u0131z\u0131n\u0131 d\u00fc\u015f\u00fcrebilir ve k\u00fc\u00e7\u00fck projeler i\u00e7in a\u015f\u0131r\u0131ya ka\u00e7abilir. \u00d6\u011frenme e\u011frisi de di\u011fer kal\u0131plara g\u00f6re daha diktir.<\/p>\n Mimari kal\u0131plar\u0131n her birinin kendine \u00f6zg\u00fc avantajlar\u0131 ve dezavantajlar\u0131 oldu\u011funu g\u00f6rd\u00fck. Ancak as\u0131l soru \u015fu: “Hangi projede hangi kal\u0131b\u0131 kullanmal\u0131y\u0131m?” Bu, geli\u015ftiricilerin s\u0131kl\u0131kla kar\u015f\u0131la\u015ft\u0131\u011f\u0131 kritik bir karar an\u0131d\u0131r. Do\u011fru mimari kal\u0131b\u0131 se\u00e7mek, projenin uzun vadeli ba\u015far\u0131s\u0131, s\u00fcrd\u00fcr\u00fclebilirli\u011fi ve bak\u0131m maliyetleri \u00fczerinde do\u011frudan etkilidir. Bu b\u00f6l\u00fcmde, farkl\u0131 senaryolar \u00fczerinden vaka analizleri yaparak, her bir kal\u0131b\u0131n hangi durumlarda parlad\u0131\u011f\u0131n\u0131 ve hangi durumlarda alternatiflerin daha iyi olabilece\u011fini inceleyece\u011fiz.<\/p>\n Proje Tan\u0131m\u0131:<\/strong> Tek ekranl\u0131 veya \u00e7ok az say\u0131da ekran\u0131 olan, genellikle CRUD (Create, Read, Update, Delete) operasyonlar\u0131na dayanan, karma\u015f\u0131k i\u015f mant\u0131\u011f\u0131 i\u00e7ermeyen, k\u0131sa \u00f6m\u00fcrl\u00fc veya h\u0131zl\u0131 prototipleme gerektiren uygulamalar. \u00d6rne\u011fin, bir yap\u0131lacaklar listesi (to-do list) uygulamas\u0131 veya basit bir hesap makinesi.<\/p>\n \u00d6nerilen Kal\u0131p:<\/strong> Bu t\u00fcr projelerde MVC<\/strong> veya MVP<\/strong> genellikle yeterli ve en uygun \u00e7\u00f6z\u00fcmlerdir. A\u015f\u0131r\u0131 soyutlama katmanlar\u0131na gerek yoktur. Geli\u015ftirme h\u0131z\u0131 \u00f6n plandad\u0131r ve “boilerplate” (kal\u0131p kod) miktar\u0131n\u0131 minimumda tutmak \u00f6nemlidir. MVC’nin basit yap\u0131s\u0131, h\u0131zl\u0131 ba\u015flang\u0131\u00e7 i\u00e7in idealdir. MVP, e\u011fer View’\u0131n test edilebilirli\u011fi biraz daha \u00f6ncelikliyse tercih edilebilir. VIPER veya MVVM-C ise kesinlikle a\u015f\u0131r\u0131ya ka\u00e7mak olur; bu kal\u0131plar\u0131n getirdi\u011fi yap\u0131sal maliyetler, projenin kendisinden daha b\u00fcy\u00fck hale gelebilir.<\/p>\n Proje Tan\u0131m\u0131:<\/strong> Birden fazla ekran\u0131, karma\u015f\u0131k kullan\u0131c\u0131 ak\u0131\u015flar\u0131 (\u00f6rne\u011fin, \u00f6deme ak\u0131\u015f\u0131, \u00fcr\u00fcn filtreleme, profil d\u00fczenleme), API entegrasyonlar\u0131 ve orta d\u00fczeyde i\u015f mant\u0131\u011f\u0131 i\u00e7eren uygulamalar. Projenin \u00f6mr\u00fc orta ila uzun vadeli olabilir ve test edilebilirli\u011fe \u00f6nem verilir.<\/p>\n \u00d6nerilen Kal\u0131p:<\/strong> MVVM<\/strong> veya MVVM-C<\/strong> bu t\u00fcr projeler i\u00e7in \u00e7ok uygun se\u00e7eneklerdir. Orta \u00f6l\u00e7ekli projelerde UI karma\u015f\u0131kl\u0131\u011f\u0131 artmaya ba\u015flar ve veri ba\u011flama yetenekleri geli\u015ftirme h\u0131z\u0131n\u0131 \u00f6nemli \u00f6l\u00e7\u00fcde art\u0131r\u0131r. MVVM, \u00f6zellikle modern UI \u00e7er\u00e7eveleriyle (React, Vue, Angular, SwiftUI, Jetpack Compose) harika bir uyum i\u00e7indedir. ViewModel’lerin test edilebilirli\u011fi y\u00fcksektir. E\u011fer uygulama i\u00e7inde \u00e7ok say\u0131da ve karma\u015f\u0131k navigasyon ak\u0131\u015flar\u0131 varsa, MVVM-C’nin Coordinator bile\u015feni navigasyon mant\u0131\u011f\u0131n\u0131 merkezile\u015ftirerek ViewModel’lerin daha temiz kalmas\u0131n\u0131 sa\u011flar ve “ge\u00e7i\u015f karma\u015fas\u0131n\u0131” (navigation spaghetti) \u00f6nler.<\/p>\n Proje Tan\u0131m\u0131:<\/strong> \u00c7ok say\u0131da mod\u00fcl, karma\u015f\u0131k i\u015f kurallar\u0131, y\u00fcksek g\u00fcvenlik gereksinimleri, uzun proje \u00f6mr\u00fc, b\u00fcy\u00fck geli\u015ftirici ekibi ve maksimum test edilebilirli\u011fin, bak\u0131m kolayl\u0131\u011f\u0131n\u0131n ve \u00f6l\u00e7eklenebilirli\u011fin kritik oldu\u011fu uygulamalar.<\/p>\n \u00d6nerilen Kal\u0131p:<\/strong> VIPER<\/strong> bu t\u00fcr projeler i\u00e7in en uygun, hatta bazen tek se\u00e7enek olabilir. VIPER’\u0131n getirdi\u011fi kat\u0131 ayr\u0131\u015ft\u0131rma prensibi, b\u00fcy\u00fck ve karma\u015f\u0131k projelerde her bir bile\u015fenin tek bir sorumlulu\u011fu olmas\u0131n\u0131 sa\u011flar. Bu, kod taban\u0131n\u0131n b\u00fcy\u00fckl\u00fc\u011f\u00fcne ra\u011fmen y\u00f6netilebilir kalmas\u0131n\u0131, farkl\u0131 ekiplerin paralel \u00e7al\u0131\u015fmas\u0131n\u0131 ve her bir mod\u00fcl\u00fcn ba\u011f\u0131ms\u0131z olarak test edilmesini m\u00fcmk\u00fcn k\u0131lar. \u00d6zellikle g\u00fcvenlik ve i\u015f kurallar\u0131n\u0131n s\u0131k\u0131 oldu\u011fu bankac\u0131l\u0131k gibi sekt\u00f6rlerde, Interactor katman\u0131n\u0131n i\u015f mant\u0131\u011f\u0131n\u0131 tamamen View\/Presenter’dan ay\u0131rmas\u0131 b\u00fcy\u00fck bir avantajd\u0131r. Evet, “boilerplate” (kal\u0131p kod) miktar\u0131 fazlad\u0131r ve ba\u015flang\u0131\u00e7ta geli\u015ftirme h\u0131z\u0131 yava\u015flayabilir, ancak uzun vadede bak\u0131m kolayl\u0131\u011f\u0131 ve hatalar\u0131n erken tespiti bu maliyeti fazlas\u0131yla kar\u015f\u0131lar.<\/p>\n Bu makale boyunca, modern uygulama geli\u015ftirmenin karma\u015f\u0131k d\u00fcnyas\u0131nda bize rehberlik eden ba\u015fl\u0131ca mimari kal\u0131plar\u0131 inceledik: MVC, MVP, MVVM, MVVM-C ve VIPER. Her birinin kendine \u00f6zg\u00fc bir felsefesi, bile\u015fenleri, avantajlar\u0131 ve dezavantajlar\u0131 oldu\u011funu g\u00f6rd\u00fck. Ancak t\u00fcm bu farkl\u0131 yakla\u015f\u0131mlar\u0131n ortak bir amac\u0131 var: yaz\u0131l\u0131m bile\u015fenlerini ayr\u0131\u015ft\u0131rarak (separation of concerns) kodun daha d\u00fczenli, test edilebilir, s\u00fcrd\u00fcr\u00fclebilir ve \u00f6l\u00e7eklenebilir olmas\u0131n\u0131 sa\u011flamak. T\u0131pk\u0131 bir terzinin, farkl\u0131 durumlar i\u00e7in farkl\u0131 tasar\u0131mlarda elbiseler dikmesi gibi, bu mimari kal\u0131plar da yaz\u0131l\u0131m\u0131n farkl\u0131 ihtiya\u00e7lar\u0131na g\u00f6re \u015fekillenen “tek bir kal\u0131b\u0131n be\u015f farkl\u0131 k\u0131yafeti” gibidir.<\/p>\n Giri\u015f seviyesinden en karma\u015f\u0131k projelere kadar, her bir kal\u0131p belirli bir problem setine \u00e7\u00f6z\u00fcm sunar. Basit uygulamalar i\u00e7in MVC veya MVP’nin sadeli\u011fi yeterli olabilirken, veri ba\u011flaman\u0131n g\u00fcc\u00fcnden yararlanmak isteyen orta \u00f6l\u00e7ekli projeler i\u00e7in MVVM \u00f6ne \u00e7\u0131kar. Navigasyon karma\u015fas\u0131n\u0131 y\u00f6netmek isteyen MVVM tabanl\u0131 projelerde MVVM-C, b\u00fcy\u00fck \u00f6l\u00e7ekli, uzun \u00f6m\u00fcrl\u00fc ve \u00e7ok say\u0131da geli\u015ftiricinin \u00e7al\u0131\u015ft\u0131\u011f\u0131 kritik projelerde ise VIPER’\u0131n kat\u0131 yap\u0131s\u0131 vazge\u00e7ilmez hale gelir. \u00d6nemli olan, “en iyi” kal\u0131b\u0131 aramak yerine, projenin mevcut ve gelecekteki ihtiya\u00e7lar\u0131na en uygun olan\u0131 se\u00e7mektir. Bu se\u00e7im, tak\u0131m\u0131n deneyimi, kullan\u0131lan teknoloji y\u0131\u011f\u0131n\u0131 ve projenin b\u00fct\u00e7esi gibi pratik fakt\u00f6rlerle de do\u011frudan ili\u015fkilidir.<\/p>\n Unutmayal\u0131m ki, mimari kal\u0131plar birer ara\u00e7t\u0131r; ama\u00e7 de\u011fil. Bir kal\u0131b\u0131 k\u00f6r\u00fc k\u00f6r\u00fcne uygulamak yerine, temel prensiplerini anlamak ve projenin dinamiklerine g\u00f6re uyarlamak \u00e7ok daha de\u011ferlidir. Geli\u015ftiriciler olarak, bu ara\u00e7lar\u0131 ne zaman ve nas\u0131l kullanaca\u011f\u0131m\u0131z\u0131 bilmek, daha kaliteli, daha y\u00f6netilebilir ve daha ba\u015far\u0131l\u0131 yaz\u0131l\u0131mlar geli\u015ftirmemizin anahtar\u0131d\u0131r. S\u00fcrekli \u00f6\u011frenme ve deneyimleme, bu alandaki yetkinli\u011fimizi art\u0131rman\u0131n en etkili yoludur.<\/p>\n 1. Hangi mimari kal\u0131p “en iyisidir”?<\/strong><\/p>\n Cevap: Tek bir “en iyi” mimari kal\u0131p yoktur. Her kal\u0131p, belirli bir problem setine ve proje \u00f6l\u00e7e\u011fine daha iyi uyar. Se\u00e7im, projenin b\u00fcy\u00fckl\u00fc\u011f\u00fc, karma\u015f\u0131kl\u0131\u011f\u0131, tak\u0131m\u0131n deneyimi, projenin \u00f6mr\u00fc ve kullan\u0131lan teknoloji gibi fakt\u00f6rlere ba\u011fl\u0131d\u0131r. \u00d6nemli olan, projenin ihtiya\u00e7lar\u0131n\u0131 analiz edip en uygun olan\u0131 se\u00e7mektir.<\/p>\n 2. Bu kal\u0131plar\u0131 sadece kullan\u0131c\u0131 aray\u00fcz\u00fc (UI) geli\u015ftirmede mi kullanabiliriz?<\/strong><\/p>\n Cevap: Bu makalede ele ald\u0131\u011f\u0131m\u0131z MVC, MVP, MVVM gibi kal\u0131plar \u00f6zellikle UI odakl\u0131 uygulamalar i\u00e7in tasarlanm\u0131\u015f olsa da, “sorumluluklar\u0131n ayr\u0131\u015ft\u0131r\u0131lmas\u0131” gibi temel prensipler yaz\u0131l\u0131m\u0131n di\u011fer katmanlar\u0131nda (\u00f6rne\u011fin, arka u\u00e7 servisleri) da farkl\u0131 \u015fekillerde uygulanabilir. Ancak bu kal\u0131plar\u0131n do\u011frudan kendileri genellikle sunum katman\u0131na (presentation layer) odaklan\u0131r.<\/p>\n 3. Bir projede birden fazla mimari kal\u0131b\u0131 bir arada kullanmak m\u00fcmk\u00fcn m\u00fcd\u00fcr?<\/strong><\/p>\n Cevap: Evet, hibrit (karma) yakla\u015f\u0131mlar olduk\u00e7a yayg\u0131nd\u0131r. \u00d6rne\u011fin, bir uygulaman\u0131n ana ak\u0131\u015flar\u0131 MVVM-C ile y\u00f6netilirken, daha basit, ba\u011f\u0131ms\u0131z mod\u00fcller i\u00e7in MVVM kullan\u0131labilir. Veya VIPER gibi kat\u0131 bir kal\u0131b\u0131n belirli mod\u00fcllerde kullan\u0131l\u0131p, daha az kritik mod\u00fcllerde daha basit bir yap\u0131n\u0131n tercih edilmesi m\u00fcmk\u00fcnd\u00fcr. \u00d6nemli olan, bu birle\u015fimin kod taban\u0131n\u0131 daha karma\u015f\u0131k hale getirmemesidir.<\/p>\n 4. Mimari kal\u0131plar\u0131 \u00f6\u011frenmek neden \u00f6nemlidir?<\/strong><\/p>\n Cevap: Mimari kal\u0131plar\u0131 \u00f6\u011frenmek, daha s\u00fcrd\u00fcr\u00fclebilir, test edilebilir, bak\u0131m\u0131 kolay ve \u00f6l\u00e7eklenebilir yaz\u0131l\u0131mlar geli\u015ftirmenizi sa\u011flar. Ayr\u0131ca, sekt\u00f6rdeki standart uygulamalar\u0131 anlaman\u0131za, farkl\u0131 projelerde ve ekiplerde daha verimli \u00e7al\u0131\u015fman\u0131za yard\u0131mc\u0131 olur. Bu, uzun vadede bir geli\u015ftiricinin kariyerinde \u00f6nemli bir fark yarat\u0131r.<\/p>\n 5. Mevcut bir projeyi farkl\u0131 bir mimari kal\u0131ba ta\u015f\u0131mak (refactor) zor mudur?<\/strong><\/p>\n Cevap: Mevcut bir projeyi farkl\u0131 bir mimari kal\u0131ba ta\u015f\u0131mak, projenin b\u00fcy\u00fckl\u00fc\u011f\u00fcne, mevcut kod kalitesine ve se\u00e7ilen yeni kal\u0131b\u0131n karma\u015f\u0131kl\u0131\u011f\u0131na ba\u011fl\u0131 olarak zorlu ve zaman al\u0131c\u0131 bir s\u00fcre\u00e7 olabilir. Genellikle, k\u00fc\u00e7\u00fck ad\u0131mlarla ve iyi test kapsam\u0131yla ilerlemek en sa\u011fl\u0131kl\u0131s\u0131d\u0131r. Bu t\u00fcr bir refactoring (yeniden d\u00fczenleme), genellikle projenin \u00f6mr\u00fcn\u00fc uzatmak ve bak\u0131m maliyetlerini d\u00fc\u015f\u00fcrmek amac\u0131yla yap\u0131l\u0131r.<\/p>\n #Yaz\u0131l\u0131mMimarisi #Tasar\u0131mKal\u0131plar\u0131 #WebGeli\u015ftirme #MobilUygulama #KodYap\u0131s\u0131<\/p>\n","protected":false},"excerpt":{"rendered":"Modern uygulama geli\u015ftirme s\u00fcre\u00e7lerinde karma\u015f\u0131kl\u0131\u011f\u0131 y\u00f6netmek ve s\u00fcrd\u00fcr\u00fclebilir kod yap\u0131lar\u0131 olu\u015fturmak hayati \u00f6nem ta\u015f\u0131r.","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"csco_page_header_type":"","csco_page_load_nextpost":"","csco_page_subscribe_form":"","csco_page_contact_form":"","footnotes":""},"categories":[1490],"tags":[],"class_list":{"0":"post-44712","1":"post","2":"type-post","3":"status-publish","4":"format-standard","6":"category-mvc","7":"cs-entry","8":"cs-video-wrap"},"yoast_head":"\nModel<\/code>‘de (veritaban\u0131ndan \u00e7ekilen \u00fcr\u00fcn bilgileri), \u00fcr\u00fcnlerin ekranda nas\u0131l g\u00f6r\u00fcnd\u00fc\u011f\u00fc View<\/code>‘da (HTML, CSS veya mobil aray\u00fcz bile\u015fenleri) ve kullan\u0131c\u0131n\u0131n \u00fcr\u00fcn filtreleme veya sepete ekleme gibi eylemleri Controller<\/code> taraf\u0131ndan y\u00f6netilir.<\/p>\n\n\/\/ Controller \u00f6rne\u011fi (Node.js\/Express benzeri)\nclass ProductController {\n constructor(productModel) {\n this.productModel = productModel;\n }\n\n async getProducts(req, res) {\n const products = await this.productModel.findAll();\n res.render('productList', { products: products }); \/\/ View'a veri g\u00f6nder\n }\n\n async addProductToCart(req, res) {\n const productId = req.body.productId;\n const userId = req.session.userId;\n await this.productModel.addToCart(userId, productId);\n res.redirect('\/cart'); \/\/ Ba\u015fka bir View'a y\u00f6nlendir\n }\n}\n<\/code><\/pre>\n<\/div>\nMVP: Sunucunun G\u00fcc\u00fcyle Daha Test Edilebilir Uygulamalar M\u00fcmk\u00fcn m\u00fc?<\/h2>\n
\n
MVVM: Veri Ba\u011flama ile Kullan\u0131c\u0131 Aray\u00fcz\u00fcn\u00fc Nas\u0131l Ayr\u0131\u015ft\u0131r\u0131r\u0131z?<\/h2>\n
\n
\n\/\/ ViewModel \u00f6rne\u011fi (JavaScript\/React benzeri)\nclass ProductListViewModel {\n constructor(productService) {\n this.productService = productService;\n this.products = []; \/\/ G\u00f6zlemlenebilir (observable) bir dizi\n this.isLoading = false; \/\/ G\u00f6zlemlenebilir bir boolean\n }\n\n async loadProducts() {\n this.isLoading = true;\n this.products = await this.productService.fetchProducts();\n this.isLoading = false;\n }\n\n \/\/ View'dan gelen bir eylem i\u00e7in komut\n selectProduct(productId) {\n \/\/ \u00dcr\u00fcn se\u00e7im mant\u0131\u011f\u0131\n console.log(\u00dcr\u00fcn se\u00e7ildi: ${productId}<\/code>);\n }\n}\n<\/code><\/pre>\n<\/div>\nMVVM-C: Karma\u015f\u0131k Navigasyonlar\u0131 Y\u00f6netmek \u0130\u00e7in Bir \u00c7\u00f6z\u00fcm m\u00fc?<\/h2>\n
\n
TransferCoordinator<\/code>, her bir ViewModel’in tamamland\u0131\u011f\u0131n\u0131 dinler ve bir sonraki ekran\u0131 ba\u015flat\u0131r. Bu yakla\u015f\u0131m, karma\u015f\u0131k kullan\u0131c\u0131 ak\u0131\u015flar\u0131na sahip mobil uygulamalar i\u00e7in \u00f6zellikle faydal\u0131d\u0131r.<\/p>\n\n\/\/ Swift\/iOS benzeri bir Coordinator \u00f6rne\u011fi\nprotocol AppCoordinatorDelegate: AnyObject {\n func didFinishLoginFlow()\n}\n\nclass LoginCoordinator: Coordinator {\n weak var delegate: AppCoordinatorDelegate?\n var navigationController: UINavigationController\n\n init(navigationController: UINavigationController) {\n this.navigationController = navigationController\n }\n\n func start() {\n let viewModel = LoginViewModel()\n viewModel.delegate = this \/\/ ViewModel, Coordinator'\u0131 dinler\n let viewController = LoginViewController(viewModel: viewModel)\n navigationController.pushViewController(viewController, animated: true)\n }\n}\n\nextension LoginCoordinator: LoginViewModelDelegate {\n func loginDidSucceed() {\n delegate?.didFinishLoginFlow() \/\/ Ana Coordinator'a ak\u0131\u015f\u0131n bitti\u011fini bildir\n }\n}\n<\/code><\/pre>\n<\/div>\nVIPER: B\u00fcy\u00fck \u00d6l\u00e7ekli Uygulamalarda Mimarinin Zirvesi mi?<\/h2>\n
\n
Vaka Analizi: Hangi Senaryoda Hangi Kal\u0131b\u0131 Se\u00e7meliyiz?<\/h2>\n
Senaryo 1: Basit Bir Not Uygulamas\u0131 veya Hesap Makinesi (K\u00fc\u00e7\u00fck Projeler)<\/h3>\n
Senaryo 2: Orta \u00d6l\u00e7ekli Bir E-ticaret Uygulamas\u0131 veya Sosyal Medya Uygulamas\u0131 (Orta \u00d6l\u00e7ekli Projeler)<\/h3>\n
Senaryo 3: B\u00fcy\u00fck Kurumsal Bankac\u0131l\u0131k Uygulamas\u0131 veya Sa\u011fl\u0131k Platformu (B\u00fcy\u00fck \u00d6l\u00e7ekli Projeler)<\/h3>\n
Sonu\u00e7 ve S\u0131k\u00e7a Sorulan Sorular: Mimari Kal\u0131plar Tek Bir Elbisenin Farkl\u0131 Modelleri mi?<\/h2>\n
S\u0131k\u00e7a Sorulan Sorular (SSS)<\/h3>\n