MVC etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster
MVC etiketine sahip kayıtlar gösteriliyor. Tüm kayıtları göster

3 Aralık 2016 Cumartesi

ASP.NET WebForms ve ASP.NET MVC Karşılaştırması

ASP.NET WebForms: Sürekle-bırak bileşenlerin kullanıldığı, olay-tabanlı programlama yapılabilen, hazır server side kontroller bulunduran ve hızlı geliştirmeye elverişli bir mimari yapı sunan, web yazılımı geliştirme platformudur.
Avantajları:
Zengin sunucu kontrolleri(Rich Server Controls) desteği; ASP.NET Web Forms'ta MVC'den farlı olarak sunucu taraflı çalışan kontroller yer almaktadır (Button, Label, Textbox, GridView, ListView, ScriptManager vs.). Bu hazır kontroller sayesinde birçok işlem kolaylıkla gerçekleştirilebilmektedir. ScriptManager  sayesinde daha az Javascript bilgisiyle AJAX işlemleri kolaylıkla yapılabilir ve sunucu kontrollerinin sürükle/bırak özelliği sayesinde daha az HTML kodu kullanarak sayfalar geliştirilebilir. Ayrıca; saf HTML'de bilindiği gibi bazı şeyler her yerde aynı gözükmeyebiliyor. Internet Explorer'da harika gözüken bir arayüz Firefox'da bozuk gözükebiliyor ya da tam tersi bir durum söz konusu olabiliyor. ASP.NET sunucu kontrolleri web tarayıcısını algılayıp ona uygun HTML içeriği sunabiliyor. Ayrıca ASP.NET Web Forms , bir sayfaya özel işlevsellikler ekleyebilen Page Controller desenini kullanır.
ViewState desteği; Normalde HTTP'nin "stateless" yapısından dolayı , HTML kontrolleri sunucu istekleri arasında değerlerini korumazlar. Ama Web Formlar'da bu durum her kontrolün son bilinen değerinin form içinde ViewState denilen bir yapıda tutulması ile aşılmaktadır. Web Forms için önemli derecede performans kaybı yaşatan View State, farklı açıdan bakıldığında yazılım geliştiricinin sayfa içinde tutması gereken değerleri/verileri kaybetmemek için sıklıkla kullandığı bir yöntemdir ViewState kullanımı sırasında çok büyük veriler saklanmadığı sürece bu konu Web forms için avantaj olarak düşünülebilir.
Olay tabanlı programlama(Event Driven Programming); Olay tabanlı programlama ile geliştirici, kullanıcı etkileşimi ile ilgilenmek için POST ve GET metotlarına bağlı kalmıyor. Bir düğmeyi sayfaya sürükleyip, ona çift tıklayarak kullanıcı düğmeye tıkladığında olacak şeyleri kod tarafında yazabiliyor. Bu yapı eğer dikkatli bir şekilde kullanılırsa, yazılım geliştiriciye büyük kolaylık sağlamaktadır. Oluşturulan olay (Event) metodu içerisinden Asp.Net'in diğer sunucu kontrollerine erişip, içerisindeki verilere müdahale edilebilmektedir.
Yukarıdaki sebeplerden dolayı yazılım geliştirici arka plandaki karmaşıklıklardan soyutlanmış olmaktadır. Sunucu kontrolleri ve ViewState'ler sayesinde daha az seviyede HTML ve JavaScript bilgisiyle yazılım geliştirici, kolay ve hızlı bir şekilde web uygulamaları geliştirebilmektedir.
Dezavantajları:
Proje Yapısı; ASP.NET Web Formları'nda varsayılan olarak gelen bir proje yapısı yoktur. Genel geçer bir proje yapısıda henüz oluşmamıştır. Herkes kendi yapısını oluşturabilir. Proje geliştikçede bu büyük bir sıkıntı olmaya başlayacaktır.
Test edilebilirlik(Unit Tests); Birim testleri yapmak çok zordur. Çünkü proje içerisindeki CodeBehind tarafında çok fazla olay tabanlı fonksiyon vardır. Ve bu fonksiyonlar iki tane parametre (Object sender, EventArgs e) içerir. Bu fonksiyonları test etmek için bu parametrelerin gönderilmesi gerekir.
Performans; Klasik ASP'deki sorunlara çözüm olan ViewState, çok kullanıldığında, aynı zamanda bir sorun haline gelebilmektedir. ViewState'ler sayfa içinde tutulduğu için sayfanın boyutunu arttırmakta ve bu da performansın düşmesine sebep olmaktadır.
HTML üzerinde daha az control; Bir çok durumda en sonunda nasıl bir HTML elde edeceğimizi bilmediğimiz için jQuery gibi JavaScript kütüphanelerinin entegrasyonu zorlaşmaktadır. Web forms ile çok fazla html kodları yönetilememektedir. Yani; sürükle bırak mantığı ile geliştirilen formlar RAD(Rapid Application Development) anlayışına uygundur ama web formlar sürekli bu şekilde geliştirildiğinde istemciye dönen HTML üzerindeki kontrol de azalır. Bu nedenle server-side olarak sunulan kontrollerin istemciye ulaştığında ID’lerini yönetmek, bu kontroller üzerinden ID Management yapmak ve JQuery gibi frameworkler ile entegrasyon yapmak çok zor hale gelir.
Arama Motoru Optimizasyonu; URL'ler bazı query string'ler ile şekillendirilebilen sabit ASPX sayfalarını göstermektedir. Bu URL’ler kullanıcı dostu olmadığı gibi aynı zamanda arama motorlarında da bulunabilirliği azaltmaktadır. Arama motoru optimizasyonu için biraz çaba harcamak gerekmektedir. Özellikle URL-Routing konusunda, hazır çözümler bulunmamaktadır.
Reusability(Tekrar kullanılabilirlik); Tekrar kullanılabilecek kodları yazmak genelde anlamsızdır. Bir formun CodeBehind tarafında tanımlanan bir GridBind olayının başka bir formun, CodeBehind sayfasında kullanılması mümkün değildir. Bunun için farklı stratejiler geliştirmek gerekir. Bu da yazılım maliyeti demektir.
Takım Çalışmasında Yetersiz; Aspx sayfaları ile onlara bağlı sunucu taraflı CodeBehind sayfaları ile beraber çalışılması gerekir. Çünkü istemci tarafı (aspx) sunucu tarafı (code-behind) ile birebir bağımlıdır. Aynı anda aynı sayfada birden fazla yazılım geliştiricinin çalışması kod karışıklığına neden olabilmektedir. Bu yüzden takım çalışmasına uygun çalışmak oldukça zordur.

ASP.NET MVC(Model-View-Controller):

Model'ler: Model; bileşeni, veriyi temsil eder. Uygulamanın veri alanıyla ilgili mantığını uygulayan parçasıdır. Model'ler uygulamadaki bir varlığın özelliklerini ve davranışlarını kapsar. Örneğin, Ürün adında bir nesne bir uygulamadaki ürünü temsil edebilir ve ÜrünAdı, ÜrünKodu gibi özelliklere sahip olabilir. Genellikle model nesneleri model durumunu veri tabanlarından alır ve veri tabanlarında saklar.
View'lar: View; model veya model'leri görsel bir sunuma dönüştürmekle sorumludur. Web uygulamalarında bu, kullanıcının tarayıcısında görüntülenecek HTML'in oluşturulması anlamına gelir. Tabii ki view'lar farklı formlara sahip olabilirler. Mesela aynı model HTML, PDF, XML hatta excel dokümanı olarak temsil edilebilir. View'lar "Separation of Concerns" mantığından dolayı verinin nasıl alındığıyla değil, sadece verinin nasıl gösterileceğiyle ilgilenmelidir. Kısacası view'lar kullanıcı arayüzünü temsil etmektedir.
Controller'lar: Controller; adından da anlaşılacağı gibi, uygulamanın işleyişini kontrol eder, view ve model arasında koordinatör gibi davranır. Controller kullanıcıdan girdiyi alır, sonra bazı işlemler gerçekleştirmek için model ile çalışır ve sonucu view'a aktarır. Diğer bileşenlerde olduğu gibi controller, verinin nasıl alındığıyla ya da sonucun kullanıcıya nasıl aktarıldığıyla ilgili bir bilgiye sahip değildir. Kısacası controller, MVC pattern içerisindeki kullanıcı etkileşimini sağlayan bileşendir diyebiliriz.
Özetle; Model; veriye ulaşan, View; veriyi sunan, Controller; veriyi işleyen katmandır.
Asp.Net MVC, hiçbir zaman Asp.Net Web            Forms’un rakibi değil bir alternatifi olarak ortaya çıkmıştır. Büyük veri kaynaklı internet projelerinde Asp.Net MVC kullanmak, hem sayfa hızlarında hem de server kaynakları kullanımında önemli bir performans artışı sağlar.
MVC Framework’ünün çıkmasının asıl nedeni ise User Interface ve Data katmanlarının birbirinden ayrılmasını zorunlu kılmaktır. Bu sayede geleceğe dönük, uygulamanın geliştirilebilirliği de artmaktadır. Daha az satır kod ile daha rahat ve kısa sürede değişiklikler yapılabilecektir. Yani tüm dünyada geçerliliği olan SOLID kod prensiplerine göre yazılım projeleri geliştirme imkanına sahip olunacaktır.
MVC ‘ye gereksinim duyulmasının diğer nedenleri; WebForms’daki kontrollerin istenildiği gibi yönetilememesi ve karmaşık sayfa çıktılarıdır. Asp.net WebForms projelerinde PostBack sonrasında da sayfadaki verilerin tutulması için kullanılan ViewState büyük ölçekli projelerde kullanıldığında boyutu giderek artmakta ve sayfaların geç açılmasının yanısıra Server’a da ayrıca yük bindirmektedir. Oysa Asp.Net MVC de ViewState ve PostBack yoktur.
Avantajları:
Proje Yapısı; ASP.NET MVC varsayılan olarak belirlenmiş bir proje yapısına sahiptir. Model-View ve Controller pattern’ına sahip, her kod geliştirme katmanı birbirinden bağımsız olarak ayrılmıştır. Bu pattern’ın kullanılması, uygulama geliştirmede karşılaşılan karmaşıklıkların önüne geçmiştir.
Test Edilebilirlik ve Reusability; MVC'de her kod geliştirme katmanı birbirinden bağımsız olarak geliştirilebilmektedir. Bu ise “Test Driven Development” yapabilmemizi sağlamaktadır. Yazılan kodun test edilebilirliği ise bize kodun tekrar kullanılabilirliğini(reusability) sağlar.Yani aynı kodu tekrar tekrar yazmaya gerek kalmaz. “Spagetti Kod” yazmaktan kurtulmuş oluruz.
Performans; ASP.NET MVC'de ViewState ve PostBack yoktur. ViewState kullanmadığı için ise sayfa içerisinde gereksiz veri tutulmamaktadır. Ayrıca; ViewState büyük ölçekli projelerde kullanıldığında boyutu giderek artmakta ve sayfaların geç açılmasının yanısıra Server’a da ayrıca yük bindirmektedir.Bu yüzden ViewState’in olmaması, çok ciddi bir performans artışı sağlamaktadır. Aynı kodun tekrar tekrar yazılmamasının da sayfa performansına katkısı vardır.
ASP.NET Web Forms ile geliştirilen projelerde, kullanılan kontroller nedeniyle (server side web controls) istemciye ciddi miktarda raw HTML döner. Sayfa render edildiğinde bu görülebilir. Fakat MVC’de HTML formlar Web formlara göre çok daha küçüktür, bu da sayfanın hızlı render edilmesini sağlamaktadır.
HTML üzerinde tam control; ASP.NET MVC, sunucu kontrollerini kullanmaz. Tek seçenek HTML input kontrollerini kullanmaktır. Yani en sonunda elde edeceğimiz HTML'in kontrolüne sahip  oluruz. HTML kontrollerinin yönetimi ve sunucuya istek gönderimi için; istemci taraflı yazılım API’lerinden, jQuery gibi JavaScript kütüphaneleri kullanılmaktadır.
Bağımsız development desteği; Asp.Net WebForms'ta bir işlem için sadece bir kişinin kodlama yapması daha sağlıklıdır. ASP.NET MVC katmanları birbirinden bağımsız olduğundan, çalışma takımındaki; bir kişi Controller, ikinci kişi View ve üçüncü kişi de Model üzerinde birbirinden bağımsız eş zamanlı olarak kod geliştirebilmektedir. Bu ise; efektif yazılım geliştirebilme, takım çalışması yapılabilmesi ve  yazılım geliştirme süresinin kısaltılabilmesi demektir.
Arama motoru optimizasyonu(SEO); Varsayılan olarak tanımlı bir URL routing bulunur. Bu routing sistemini spesifik olarak genişletme imkanımız vardır. Böylece anlaşılır URL’ler üretme imkanına sahip olunmaktadır. Üretilen spesifik URL’lerin SEO ya katkısı da oldukça fazladır.
Genişletilebilirlik; ASP.NET MVC Razor, Spark, NHaml, …v.s gibi birden fazla görüntü motorunu(View Engine) destekler. Hatta gerekirse yazılım geliştiriciler kendi görüntü motorlarını oluşturup implemente edebilmektedirler.
Dezavantajları:
Olay tabanlı programlamanın, ViewState ve PostBack’ in olmayışı, temel HTML, JS ve CSS bilgisine gereksinim duyulması, yeni başlayan Web Application Developer lar için biraz daha fazla öğrenme çabası gerektirmektedir.
ASP.NET WebForms’tan ASP.NET MVC’ye geçiş yapılmak istendiğinde; direk Upgrade veya Migration mümkün olmamaktadır.
ASP.NET WebForms mu? ASP.NET MVC mi?
Peki bir web yazılımı projesi geliştirirken, yukarıda bahsettiğimiz yazılım geliştirme platformlarından hangisini tercih etmeliyiz?
Yukarıda, ASP.NET WebForms  ve ASP.NET MVC platformlarının birbirinin yerine değil de yazılım proje gereksinimlerinin değişmesine bağlı olarak ortaya çıktığını ifade etmiştik. Yani bir Web uygulamasında aynı anda hem ASP.NET WebForms, hem de ASP.NET MVC API’leri kullanılabilmektedir. Bu yüzden; Yazılım ekibindeki personelin yazılım geliştirme yetenekleri, geliştirilecek olan yazılımın teknik ve donanımsal alt yapısı, geliştirilecek olan yazılımın diğer tüm gereksinimleri(istenilen bitirme süresi, …vs.) gibi kriterlere göre yukarıda belirttiğimiz avantaj ve dejavantajları göz önünde bulundurarak karar vermek gerekir. Örneğin kısa zamanda bitirilmesi istenen küçük bir proje için ASP.NET WebForms u , ancak büyük ölçekli bir yazılım projesi için ise ASP.NET MVC ‘yi tercih etmek daha doğru olur, gibi. Karar verebilmek için mutlaka; yazılım proje gereksinimlerinin, kullanılacak yazılım geliştirme platformunun avantaj ve dezavantajlarına göre ele alınarak değerlendirilmesi gerekmektedir.

Kaynaklar:

17 Haziran 2015 Çarşamba

MVC, MVP, MVVM Design Patterns nedir?

MVC (Model-View-Controller); Yazılım geliştirme teknolojilerinde kullanılan, Seperation Of Concern(Yazılımda işlev ve özelliklerin soyutlanarak birbirinden ayırılması) prensibini vurgulayan yazılım tasarım desenidir. İlk kez 1979 yılında “Trygve Reenskaug” tarafından tanımlanmıştır.

Kullanıcı View i görür, Controller ı kullanırlar. Controller Modeli manipule eder veya View i update eder. View, kullanıcı arayüzünü kullanıcıların görmesini ve Controller ı tetiklemesini sağlar.

Modelin Sorumlulukları: Property lerinde veri depolar, uygulama yöntemlerini implemente eder(data and logic), View 'ın register ve unregister methodlarını sağlar,View 'deki durum değişikliklerini uyarır, uygulamanın iş mantığının uygulanmasını sağlar.
View in Sorumlulukları: Arayüzü oluşturur, Model deki değişikliklerde arayüzü günceller, kullanıcı girişlerini Controller'a iletir.
Controller ın Sorumlulukları: Kullanıcı girişlerindeki değişiklikleri Modele iletir, eğer değişiklik yüzeysel ise View'i update eder.

MVP (Model-View-Presenter) ise; MVC de mimarisinde eksiklik olarak görülen sorunlara çözüm olarak 90’lı yıllarda ortaya çıkmıştır. İlk olarak Mike POTEL tarafından bir makalede popüler olmuştur. Daha sonra Martin Fowler ve Derek Greer tarafından da makalelerde ele alınmıştır. Daha sonrasında MVVM(Model View ViewModel) gibi mimari tasarım desenlerine de ihtiyaç duyulmuştur. İhtiyaca göre halen yeni pattern lar geliştirilmeye devam edilmektedir.
                              Şekil : Model View ViewModel
            MVC ‘deki Controller ın View ile daha az etkileşimde olduğu farkedilerek, Controller ın yerine Presenter katmanı tasarlanmıştır. Controller dan farklı olarak Presenter katmanı View ile direkt olarak etkileşim halinde dir.
Şekil : Genel MVP Design Pattern gösterimi.
MVP tasarımı deseni, view’in sorumluluğunu biraz daha arttırarak Controller sınıfını ortadan kaldırmıştır. View’deki veri durum yönetimini ve kullanıcıdan gelen komutları işlemek için presenter sınıfı bulunmaktadır. Presenter ve view arasında one-to-one bir ilişki bulunmaktadır. Bu sayede UI için test kodu yazmamız gerektiğinde ilgili Presenter’a test kodu yazabiliriz. Kullanıcı View’den isteği yaptığında bu istek önce ilgili Presenter sınıfına düşer. Presenter bu isteği modele göndererek dönen cevaba göreView’i update eder.
Passive View (PV) Yaklaşımı :
MVP’nin uygulanmasıyla alakalı iki farklı yaklaşım vardır. Bunlardan biri Supervising Controller olarak adlandırılmıştır. İki yaklaşımda da durum yönetimi View üzerinde yapılır, Presenter sınıfı View’den haberdardır.


Passive view yaklaşımında Presenter sınıfı View ile Modelin arasındaki senkronizasyondan tamamen sorumludur. View sınıfının model ile en ufak bir ilişkisi yoktur. Bütün iş mantığı Presenter sınıfı üzerinde yapılır. Bütün senkronizasyonu Presenter sınıfı sağlar. Bu yaklaşımında View’in çok fazla bir sorumluluğu yoktur. Yaklaşımın adından da anlaşılabileceği gibi pasif kalmıştır. View kendisinin değiştiğini bir event fırlatarak Presenter sınıfına haber verir. Presenter da ilgili model sınıfını günceller.
Supervising Controller (SC) Yaklaşımı :
Supervising Controller yaklaşımında ise, Presenter kompleks UI iş mantığını barındırır. View, modele binding mekanizması olan bir teknolojiyle bağlanarak veriyi çeker. Presenter sınıfı, view tarafından çağırılabilecek olan metotlara sahiptir. Controller sınıfındaki gibi hangi View’in gösterileceğine Presenter sınıfı karar vermez. Presenter sınıfının çağırılması için View’den kod yazılması gerekir. Bir View metodu, Presenter sınıfı tarafından çağırılabilir.
UI için test yazılması gereken projelerde MVP tasarım kalıbı kullanmamız MVC’ye göre daha uygun olur. Çünkü, bütün UI iş mantığı, Presenter sınıfı içerisindedir. Yani Presenter, bir nevi UI’ın kendisi durumundadır. Birden fazla UI teknolojisiyle çalışmamız gereken zaman MVP kullanmak daha mantıklıdır. Çünkü, Presenter sınıflarımız yeniden kullanılabilirliği arttıracaktır. Son derece kompleks UI iş mantığınız varsa veya kullanıcıyla etkileşimi yoğun olan sayfalarınız projenizin büyük bir çoğunluğunda yaygınsa; burada MVP tasarım kalıbı kullanmanın avantajı olacaktır. Bütün iş mantığı sayfanın Presenter sınıfında olacağı için işlem yapmak daha kolay olur. Test edilebilirlik uygulamanız için önemliyse o zaman Passive View yaklaşımı tercih edilmelidir. Çünkü bütün işleyiş onun üzerinde gerçekleşecektir. Ancak, kodun okunabilirliği, daha az karmaşık olması, test edilebilirlikten daha önemliyse, o zaman Supervising Controller yaklaşımı tercih edilmelidir. Çünkü, burada sorumluluğun bir kısmı Presenter sınıfının üzerinden alınmıştır. View ile model arasında bir binding mekanizması kurularak senkronizasyon sağlanmıştır. View sınıfındaki her değişiklikte Presenter sınıfının güncellenmesi gerekmeyecektir.

Çok Katmanlı Design Pattern Mimarilerinin Faydaları:
  1. Kod karmaşasının önüne geçer,
  2. Her katmanda ayrıca kod geliştirmeye izin verir(Front-end, back-end development),
  3. Daha rahat test edilebilir uygulamalar geliştirebilmeyi sağlar,
  4. Yazılım Mimarisi olarak, sorumlulukların birbirinden bağımsız olarak paylaştırılması, geliştirilecek olan yazılımın yönetimini, ölçeklenebilirliğini, geliştirme hızını artırır, bakımını kolaylaştırır.


Kaynaklar: