ASP.NET WebForms MVC'ye ne zaman tercih edilir

Microsoft'un söylediğini biliyorum

ASP.NET MVC, WebForms'un yerine geçmez.

Bazı geliştiriciler, WebForms'ın geliştirilmesinde MVC'den daha hızlı olduğunu söylüyor. Ancak kodlama hızının teknolojiyle konfor seviyesine indiğine inanıyorum, bu yüzden bu konuda hiçbir cevap istemiyorum.

ASP.NET MVC'nin bir geliştiriciye uygulamaları üzerinde daha fazla kontrol sağladığı göz önüne alındığında, WebForms neden eski kabul edilmiyor? Alternatif olarak, yeni gelişim için WebForms'u MVC'ye göre ne zaman tercih etmeliyim?

Webforms - MVC şu anda sıcak bir konu gibi görünüyor. Tanıdığım herkes MVC'yi bir sonraki harika şey olarak görüyor. İçimdeki ufak yavrularımdan, sorun yok gibi görünüyor ama hayır, web formlarının sonu olacağını sanmıyorum.

Akıl yürütmem ve webforms'un MVC üzerinden neden seçileceği konusundaki akıl yürütme, birinin diğerinden daha iyi olandan ziyade iş perspektifiyle daha fazla ilgisi var.

Web formlarının MVC üzerinden seçilmesinin en büyük nedenleri zaman / paradır.

Ekibinizin çoğu web formlarını biliyorsa ve MVC'yi hızlandırmaya vaktiniz yoksa, üretilecek kod kaliteli olmayabilir. MVC'nin temellerini öğrenmek, sonra içine atlamak ve yapmanız gereken karmaşık sayfayı yapmak çok farklı şeylerdir. Öğrenme eğrisi yüksektir, bu yüzden bunu bütçenize yansıtmanız gerekir.

Tüm web formlarında yazılmış büyük bir web siteniz varsa, sitenizde çok farklı iki sayfa türünün olmaması için web formlarında yeni sayfalar oluşturmaya daha yatkın olabilirsiniz.

Burada ya hep ya hiç yaklaşımı olduğunu söylemiyorum, ama özellikle takımdaki herkes MVC'ye aşina değilse, her ikisinin de bölünmesi durumunda kodunuzu korumayı zorlaştırır.

Şirketim yakın zamanda MVC ile üç test sayfası yaptı. Oturduk ve onları tasarladık. Karşılaştığımız bir sorun, ekranlarımızın çoğunun aynı sayfada Görüntüle ve Düzenle işlevine sahip olmasıdır. Sayfada birden fazla forma ihtiyaç duyduk. Hayır biggy, ama o zamanlar ana sayfasını kullanmazdık. Hem web formları sayfalarının hem de MVC sayfalarının ortak görünüm ve his için aynı ana sayfayı kullanabilmesi için yenilemek zorunda kaldık. Şimdi fazladan bir yuva katmanımız var.

Bu sayfalar için yepyeni bir klasör yapısı oluşturmamız gerekiyordu, böylece uygun MVC ayrımını takip ediyordu.

3 sayfa için çok fazla dosya olduğunu hissettim, ama bu benim kişisel görüşüm.

Bence, sitenizi MVC'yi kullanmak için güncellemeye yatırım yapmak için zamanınız / paranız yoksa MVC üzerinden web formları seçersiniz. Buna yarı yarıya yaklaşan bir yaklaşım yaparsanız, şu an sahip olduğunuz web formlarından daha iyi olmaz. Daha da kötüsü, üst yönetim onu ​​bildiklerinden daha aşağı bir şey olarak görebileceğinden, bu sorun çözülürse, şirketinizde bozulma ihtimaline bile sahip olabilirsiniz.

3 yıl boyunca ASP. Net WebForms uygulamaları geliştirdim ve bir gün MVC dersi verdikten sonra satıldım. MVC neredeyse her zaman daha iyi bir çözümdür. Neden?

• Sayfa lifecylce daha basit ve daha verimli
• Html kontrolleri dışında kontroller gibi bir şey yoktur. ASP. Net'in ne ürettiğini görmek için çıktınızı hata ayıklamanız gerekmez.
• ViewModels size büyük bir güç verir ve manuel kontrol bağlama ihtiyacını ortadan kaldırır ve bağlama ile ilgili birçok hatayı ortadan kaldırır.
• Bir sayfada birden fazla form olabilir. Bu WebForms'un ciddi bir sınırlamasıydı.
• Web, vatansızdır ve MVC, web mimarisiyle daha yakından eşleşir. Webforms, ViewState'i tanıtarak durumu ve bununla ilgili hataları tanıtır. ViewState otomatiktir ve arka planda çalışır, bu nedenle her zaman istediğiniz şekilde davranmaz.
• Web uygulamaları bugünlerde ajax ile çalışmalı. Artık tam sayfa yükleme yapmak kabul edilemez. MVC, JQuery ile ajax'ı çok daha iyi, daha kolay ve daha verimli hale getirir.
• Bir sayfada birden fazla form olabilir ve mimari URL'lere yapılan çağrılarla yönlendirildiğinden, ajax gibi korkak şeyleri JQuery kullanarak geçerli sayfanıza düzenleme formu gibi farklı bir form yükleyebilirsiniz. Bunun size neler sağladığını anladıktan sonra, inanılmaz şeyleri kolayca yapabilirsiniz.
• ASP. Net WebForms sadece html üzerinden bir soyutlama değildir, aynı zamanda son derece karmaşık bir çözümdür. Bazen çok garip bir böcek bulabilir ve gerekenden çok daha uzun süre onunla mücadele edebilirsin. Çoğu durumda neyin yanlış yaptığını görebiliyordunuz, ancak bu konuda hiçbir şey yapamıyorsunuz. Sonunda garip geçici çözümler yapıyorsun.
• WebForms, tasarımcılar için iyi bir teknoloji yapmaz. Tasarımcılar genellikle doğrudan html ile çalışmayı sever. MVC'de bu bir manzara, WebForms'ta yarım günlük bir çalışma.
• Web platformu hızlı bir şekilde geliştikçe WebForms yetişemeyecektir. HTML5'in yeni etiketlerinin veya özelliklerinin farkında değil, pahalı 3. taraf denetimleri almadığınız veya Microsoft'un bir güncelleştirme yayımlamasını beklemediğiniz sürece yine de aynı işlemleri gerçekleştirecek.
• WebForms'daki kontroller sizi birçok yönden sınırlandırır. MVC'de bir JQuery kütüphanesini kapıp şablonlarınıza entegre edebilirsiniz.

WebForms geliştikçe yukarıdaki sorunların bir kısmının ele alındığını biliyorum, ancak bu benim orijinal deneyimimdi. Sonuçta, bir proje zaten kullanmıyorsa WebForms için bir iş vakası bulmak son derece zor olacaktır.

Microsoft'ta bir MVC uzmanı olan Scott Guthrie'ye e-posta gönderdim . Ve muhtemelen bu soruyu cevaplayacak en nitelikli adam. Cevap verecek kadar kibardı:

"Farklı müşteriler farklı programlama yaklaşımları ararlar ve birçoğu WebForms'u sever ve bunun harika olduğunu düşünür. Diğerleri MVC'yi sever ve harika olduğunu düşünür. Bu yüzden ikisine de yatırım yapıyoruz."

Yani, bu bana teknik bir konu olmadığını söylüyor. İsterseniz onun daha bir "yumuşak sorun". Kişisel tercihlerden biri. Bu, birkaçınızın söylediklerine uygun.

Tüm cevaplar için teşekkürler.

Bu çok fazla cevabı olan eski bir soru ama hiçbiri listelenmesini beklediğim bir cevabı yoktu.

Kısa cevap:

• ASP.NET platformu için modern programlama kuralları ve sektöre yönelik kalıpları içeren bir web uygulaması düzgün şekilde oluşturmak istiyorsanız, ASP.NET MVC kullanın. Aşağı tarafta, HTML ve müşteri tarafı kaynaklarının (Javascript, CSS) nasıl çalıştığını bilmenin yanı sıra dik bir öğrenme eğrisi olan ancak kavradığında ani bir sona ulaşan MVC programlama zihniyetinde rampa oluşturmanız beklenir.
• Bir GUI merkezli, RAD (Hızlı Uygulama Geliştirme) , sürükle ve bırak yaklaşımını kullanarak çok hızlı bir şekilde prototipleme yapmak için ASP.NET Web Formları kullanın , örn. 15 dakika ve çözüm geliştiricilerin desteklediği bir şey değildir. Veya, GUI veya Windows Forms geliştirmesinde bir geçmişiniz varsa ve bilgilerinizi Web’e aktarmak istiyorsanız , ASP.NET Web Formlarını kullanın .

Ancak buna düzgün bir şekilde bakmak için her birinin tarihini anlamanız gerekir.

ASP.NET Web Formları, Visual Basic 6 ActiveX denetimlerini, sunucudaki VB6 DLL'leri ve ASP Classic'i kullanarak dinamik web uygulamaları geliştirenlere Microsoft'un cevabıydı. O zamanlar, bu Microsoft araçlarını kullanarak web geliştirme gerçek bir karışıklıktı. Microsoft'un çıktısı olan .NET Framework'ün bütünüyle beraber, aslında Windows yığında verimli bir iş programcılığının nasıl yapıldığına dair çizim tahtasına geri dönerken, ASP.NET Web Forms, günlerinde şaşırtıcı ve güzeldi.

Tüm yaklaşım, geliştiricilere, Windows uygulama geliştirmeye çok benzeyen, ancak internet hizmetlerinin gücüyle her iki dünyanın da en iyisini sunmaktı. Fikir, tıpkı bir VB6 / WinForms "Form" (bir pencere) ile aynı şekilde bir web sayfasının bir form (tıpkı bir pencere gibi, bkz.) Olduğu gibi ve bu formda etiketleri, metin kutularını sürükleyip bırakabilmenizdi, veri ızgaraları, düğmeler ve VB / WinForms GUI geliştiricilerinin alıştığı diğer şeyler.

Bir düğmenin bir şey yapmasını sağlamak için, sürükleyip bıraktıktan sonra, tasarımcıya çift tıklayın ve kod editördesiniz, bu "click" olayı gerçekleştiğinde ne yapacağınızı söyleyin. Bu tam olarak Windows GUI geliştiricilerin VB6'nın GUI araçlarını ve rakip araçlarını kullanarak yazılım oluşturmasıydı , ancak şu anda kod sunucuda yürütülüyor! Vaov!

Bu 2002 teknolojisiydi. RAD gelişimi için internet destekli GUI çözümlerine bir cevap olarak zamanında şaşırtıcı ve güzel olan, başarması gereken iş hedefleri olan dağınık yazılım geliştiricilerin dünyasına bir güç duygusu getirdi.

Ne yazık ki, bu programlama modeli, Windows GUI programlamanın metaforunu, gerekli uygulama ayrıntılarının yükünü, olay yaşam döngülerine uyum sağlamak için gerekli tüm sarmalayıcı bagajı ve basit HTML'nin çirkin ayrıntılarını kesmeyi vurgulamaktadır. Bu sürükle ve bırak bileşenlerinin ve kontrollerinin çıktı vereceği komut dosyası. Günün sonunda, gerçek uygulamaları destekleyen geliştiricilerin kaçınılmaz olarak bu bileşenlerin içine girmeleri ya da kendi parçalarını yazmaları gerekiyordu ve sonuç olarak bu altyapı ile savaşacaklardı; gözyaşları.

Yedekle Ellerini yıka. İş sorununa tekrar bakalım. İş hedeflerimiz neler?

Web uygulamaları oluşturmalı ve yönetmeliyiz . Kısıtlamalarımız, HTTP, HTML, Javascript ve CSS'de yer alan World Wide Web’e sahip olduğumuz ve sunucuda iş kurallarımız, veritabanlarımız ve küçük programlama dilleri (örneğin, C #). Geliştirme metodolojimizi yönlendirmek için gerçekten bu Windows GUI metaforuna ihtiyacımız var mı? Neden sadece uygulama sorunlarına odaklanamıyoruz ve GUI metaforlarını yapmıyoruz?

ASP.NET MVC'nin devreye girdiği yer burasıdır. Kendisini doğru ve saf yazılım geliştirme ilkelerine geri dönmek isteyen "Alt.Net" adı verilen geliştiricilerin isyanıyla başladı. Daha fazla telaş ve telaş yok, sadece iş hedeflerine ve yazılım en iyi uygulamalarına odaklanın.

Bu durumda bunun gerçekten ne anlama geldiği:

1. Kaygıların ayrılması . Örneğin, bir veri bileşeninin verilerinin nasıl işleneceğini bilmesi gerekmez, biçimlendirmeyi görüntülediğinde veritabanı bağlantısı yapılandırma ayrıntılarıyla donatılmamalıdır ve bu şekilde bir geliştirici düzenleme yaparken kendi ilgi alanına odaklanabilir. Test kodu
2. HTML ve ilgili kaynakların nitty kumuna maruz kalma için maruz kalma ve tam destek . Web Formlarında, HTML gizlenir, geliştiriciler bununla uğraşmaktan caydırılır. ASP.NET MVC’de geliştiricilerin bu ayrıntıları yönetmesi daha çok teşvik edilmektedir; aslında bir zorunluluktur. Buradaki avantaj geliştirici HTML, CSS ve script temiz semantiğini takdir yeniden öğrenmek ve çalışabilir olmasıdır ile bunun yerine ona karşı.
3. İş nesnelerinin test edilebilirliği . Kontrolörler ve modeller, programatik ünite testi için çok daha uygundur, bu nedenle uygulamaların iş hedeflerine uygun olduğu doğrulanabilir ve değişikliklerin bozulmayacağı doğrulanabilir. Web Formları ile, bileşenlerin ayrı ayrı test edilmek üzere tasarlanmadığı ve tüm geliştirme çıktılarının sayfa formları ve bunların olay yaşam döngüleri etrafında iş mantığı ve sunum mantığı ile iç içe geçtiği için test edilmesi zordu .

Javascript'in yüksek düzeyde bir programlama dili olduğu gibi HTML’nin de zaten çok yüksek bir biçimlendirme dili olduğunu unutmayın. Assembly dili ve C ile ilgileniyor olsaydık, tüm hikaye farklı olurdu.

ASP.NET MVC'nin bir diğer amacı, 2 numaraya genişleyerek, geliştiricilerin çözümlerinin 'görünüm' kısmının ön uç ayrıntılarını düzenlemelerini ve endüstrinin geri kalanının oluşturduğu zengin temelden faydalanmalarını sağlamaktır. ön uç müşteri platformu.

ASP.NET MVC geliştiricilerinin, sunucu tarafı mimarisiyle mücadele etmeden zengin Javascript kütüphanelerini ve istemci tarafı şablonlama tekniklerini kullanarak kendilerini evde hissettiğini göreceksiniz. Bu aslında ASP.NET Web Formları için geçerli değildi, çünkü Web Formları HTML veya komut dosyasına bakmanızı istemiyor, çünkü gerçekten yapmak zorunda olmadıkça , bu durumda dikkat etmeniz gereken bir durum yok. Kalbin

Tam ve toplam bir ASP.NET MVC dönüştürücüyüm ve geriye bakmadım, bu da hala çok büyük WebForms uygulamalarını sürdürmem gerektiğini söyledi. İşte benim almam:

WebForms
Bunları, ızgaralarla ilgili ciddi ağır kaldırmalarınız olduğunda kullanın. Izgara kontrolleri, tablo biçiminde güzel bir şekilde uyan basit bir veri kümesine sahip olduğunuzda ve kullanıcıların kayıtları güncellemesi için basit bir yol sağlamak istediğinizde gerçekten çok iyidir. Evet, MVC 4’ün harika çalışan Ajax liste türü bir şeye sahip olduğunu biliyorum ama harika olanı işimizde sık sık dün çalışan bir şeye ihtiyacımız var ve eski moda ızgaralar harika çalışıyor ve kullanıcılar mutlu oluyor Glee ile ızgara boyunca sekme yapabiliyor. Benim için bu benim için WebForms ile ilgili en iyi şey; ama, Ryan olarakWebForms uygulamasının büyük bir zaman karışıklığı olabileceğine dikkat çekti, çünkü çitin her iki tarafını da şık bir kod arkasındaki dosyadan oynatıyorsunuz. Tüm denetleyici tipi öğelerinizi görünümlerinize karıştırmak aynı anda hem gül hem de diken olabilir.

MVC
Bunu gerçekten kullanmak isterseniz ve bir uygulamayı sıfırdan başlatma fırsatınız olduğunda bunu kullanın. Açıkça tanımlanmış bir MVC uygulamasına sahip olmak, işe başlamak için biraz daha fazla bir iştir ancak bakımdaki faydaları, ilk kurulum maliyetinden daha ağır basar. İlginç Ajax etkileşimleri yapmak istiyorsanız, modelinizi temiz url'ler ve yollar gibi kodla yazmayı tercih edin ve uygulamanızın akışının tamamını kontrol edebilmeyi tercih edin. İlk başta alışmak biraz zaman alıyor ancak Greenfield uygulamaları için daha iyi bir seçenek olduğunu düşünüyorum.

Sonuç olarak, benim için bu, şebekelere ve! :)

Benim deneyimim:

• CakePHP projelerini bir yıllığına yazdı.
• Altı ay boyunca orta büyüklükte bir Webforms projesi tamamlandı.
• Windows Forms projesinde üç yıl çalıştı.

Bu deneyimden sonra, webforms kullanarak başka bir uygulama yazmayı denedim ve webforms'ın geliştiriciyi html, javascript ve css kullanan bir uygulama geliştirdikleri gerçeğinden korumak için nasıl bir gün uğraştığını hayal kırıklığına uğrattım.

Daha sonra MVC'yi denedim ve çıktı üzerinde daha fazla kontrol sahibi oldum (ve CakePHP'den MVC paradigması ile biraz tecrübe edindim), bu basit uygulamayı tam olarak günde yaklaşık 1 / 2'de istediğim gibi tamamlayabildim.

JQuery gibi güçlü UI çerçevelerinin mevcudiyeti, çoğunlukla hacimli önceden oluşturulmuş UI bileşenlerinin kullanılması lehine çıktının doğrudan kontrolünden vazgeçme cazibesini büyük ölçüde ortadan kaldırır.

Web formlarını tercih ediyorum çünkü arkaplanım windows geliştirme.

Geliştirme hızı önemli bir konudur ve bir gecede formlarla bir geceyi düzeltmek için Hindistan'daki birine kolayca iletebilirim. Ayrıca, eğer bir sayfada bir hız sorunum varsa, asp.net hızı hakkında gerçekten iyi bir kitap kullanışlıdır (Rick Kiessig adamdır).

webforms ex windows insanlar için mvc web insanlar için

Ancak, Rick'in müthiş bir kitap yazdığı modern dünyada, sunucuları Hindistan'da günlük hızlı ve ucuz kodlayıcıların artmasıyla, webforms'un üstünlüğü var.

Benim 2 kuruş, seçeneğiniz varsa, her zaman ASP.NET MVC'yi yeni projeler için kullanmaktır. Bana göre web formları, web uygulamaları geliştirmek için iyi bir yol değil.

Temel REST’in kaldırılmasının kötü olduğunu, postback modelinin tümünün kötü olduğunu, html / css’in GUI editörüne güvenerek verildiğinin kötü olduğunu düşünüyorum, sihirbazlar ve GUI’lerin bazı şeyleri ayarlamak için kötü olduğunu, URL’lerin kötü olduğunu düşünüyorum. kötüler.

Tüm cevapları okudum ve kişisel deneyimimin yukarıdaki cevaplara bir şeyler ekleyeceğini hissediyorum.

3-4 yıl önce, Webforms kullanarak 2-3 web sitesi projesi geliştirdim. O zamanlar, MVC etrafta değildim ya da duymadım. Gelişim doğaldı (daha önce web geliştirme deneyimim olmadan Win-form geliştirmeden geliyordum) benim için hızlıydı, çünkü HTML'yi ayrıntılı olarak öğrenmem gerekmiyordu ve web kontrolleri çok yardımcı oldu (cehennem, hayatı kolaylaştırdı) .

Şimdi, onca zamandan beri, yakın zamana kadar herhangi bir web projesinde çalışmıyordum ve sadece WPF kullanarak bazı windows uygulamaları inşa ediyordum.

Birkaç gün önce bir web sitesi için bir fikrim vardı ve onu geliştirmeyi düşündüm: bu sefer MVC'de (her yerde konuşulduğundan beri, her ikisini de öğrenmem gerekiyordu, bu yüzden MVC'yi seçtim). Proje hala gelişim aşamasında, çünkü hala birlikte öğreniyorum ve yapıyorum.

Yani, s / b bulduğum temel farklılıklar aşağıdaki gibidir: -

• Windows geliştirmesinden gelen biri için Web formları her zaman uygun olacaktır. Bir windows geliştirici için Asp.net öğrenme eğrisi biraz dik

• Web geliştirmeden başka bir teknolojide gelen biri için MVC, hepsinden alay ettiği için tercih edilecektir.

• İyi HTML ve CSS bilgisine sahipseniz, MVC'de geliştirme daha kolay ve temizdir

• Dağıtım hala bir konudur. Web formlarında kopyalayıp yapıştırmak için sadece bir tane gerekli. Ancak, bu yapılması gereken bazı şeyler gerektirir.

Kısacası, ikisi de bir süre burada kalacak.

Henüz bu konuya verilen 15 cevap arasında öne sürülen bu düşünceyi görmedim, ancak düşünmeye değer olduğunu düşünüyorum.

Deneyimlerime göre Web Formları, Win Forms ve WPF ile MVC'den daha benzer. Bunu göz önüne alındığında, ekibin bu tür teknolojide en fazla deneyime sahip olduğu durumlarda veya Web Formları projesinin varolan (veya aynı zamanda geliştirilen) Win Formları ile aynı veri kümesine bir arabirim sunacağı durumlarda Web Formları seçmeyi düşünebileceğini düşünüyorum. WPF projesi. Bunu yapmak, geliştiricilerin projeler arasında daha kolay geçmelerini sağlar, çünkü uygulama mantığı ikisi arasında oldukça benzer olabilir.

Diğer cevapların da belirttiği gibi, MVC çerçevesindeki gelişme Ruby, PHP, Python vb. Web geliştirmelerine Microsoft'a göre daha benzerdir; bu nedenle doğal olarak MVC seçimi, bu alanlardaki ekiplerin deneyiminden ve diğer cevaplarda sunulan faktörlerden etkilenebilir.

Birkaç yıl önce MVC'ye gitmeme sebebimiz, Microsoft'un olgunlaşmamış bir teknolojisiydi. Geçtiğimiz birkaç yıl boyunca şimdi daha olgun bir sürümdeyiz (4) ve MS, bunun nereye gittiğini hesapladı gibi görünüyor. Bununla birlikte, sürüm 4'te kullanmak istediğimiz özellikler olarak MVC kullanan büyük LOB uygulamaları geliştirmek konusunda hala isteksiziz, Windows 2012 sunucusu (IIS8 üzerinden web yuvaları). 1 yıl daha, MVC’nin daha fazla kabul edeceğimizi, umarım daha fazla üçüncü taraf kontrolleri olacağına, teknolojinin yerleşmiş olacağına ve bunu destekleyecek altyapıya sahip olacağımıza inanıyorum.

Bu karar tercihlerinize, gereksinimlerinize ve hatta bilgi ve deneyiminize bağlıdır.

Eğitim MVC öğrenme veya bir teslim almak için zaman. Bütün bunlar bir ya da başka bir yaklaşımı seçmek için önemlidir.

Bu bir diğerinden daha iyi değil mi, sadece hem yaklaşım hem de çerçeveler artı ve eksilere sahip.

Kişisel olarak MVC 3'ü tercih ediyorum, kendi deneyiminizi edinmeyi denemenizi öneririm, ancak MVC'deki programın temiz, eğlenceli, esnek, genişletilebilir, güvenli ve yapılandırılmış bir yol olduğunu söylemeliyim.

Saygılarımızla,

MVC yerine WebForms'ı seçmemin tek nedeni, WebForms için MVC'den çok daha fazla 3. parti UI kontrolünün bulunmasıdır. MVC'yi seçtim çünkü WebForms ile çok çalıştım ve yeni / yeni bir şeyle çalışmak istiyorum ama yine de MS dükkanından :)

Temel olarak, hiçbir şey WebForms'ta görünüm alanını kapatmanızı ve ViewModels'i ve model bağlama ve sunucu tarafı denetimleri yerine döngüler için if / for kullanmasını engellemez.

Bu WebForms veya MVC kodu:

<% foreach (var item in Model.Items) { %>
<p><%: item.Name %></p>
<% } %>

WebForms'da bulduğum tek sınırlama, Bağımlılık Enjeksiyonu / Tersine Çevirme Kontrolü kullanıyorsanız, WebForms sayfalarının parametresiz bir yapıcıya sahip olması gerektiği için yapıcı enjeksiyonuna sahip olamayacağınızdır, bu nedenle özellik enjeksiyonunu kullanmanız gerekir. Bu gerçekten bu kadar büyük bir mesele mi?

ASP.NET MVC gerçekten Ruby'nin bir cevabı ve tarayıcıyı (istemci) sunucudan mümkün olduğunca ayırmanın yeni, modaya uygun ve (IMO) daha iyi bir yoludur.

ASP.NET Webforms , istemci tarafında sunucu tarafında size hemen hemen her şeye doğrudan erişime sahip olduğunuzdan çok fazla kontrol sağlar. Temel olarak görüşünüz ve denetleyiciniz aynıdır, bu size çok fazla güç verir ve çoğu zaman çok fazla karışıklık yaratır.

ASP.NET MVC , .aspx dosyasının ve web formlarında onlara eşlik eden .aspx.cs dosyasının sıkı bağlantılarını ayırarak görünümü ve denetleyiciyi ayırır.

Temel olarak fark, verileri görüntüleme dosyasına görüntülemek için işlemden çok daha fazlasına (tipik olarak hepsine) sahip olmak ve iş mantığını ve geri kalanını denetleyicide bırakmak, her ikisini de kongre yoluyla daha temiz tutmak ve aynı zamanda her birine daha az erişim sağlamaktır. web formlarından başka izin verir.

Benim düşünceme göre, onlar yeterince ilişkili ve kabaca tercihlerine göre gereken kabiliyetlere sahipler.

Harika bir WebForms geliştiricisi, harika bir MVC geliştiricisi kadar güçlü bir ürün üretebilir. Ancak kendisini Web’de MVC’yi benimsemeye zorlayan büyük WebForms geliştiricisi kısa sürede ortaya çıkacak. Aynı şey WebForms’a bir şans veren harika bir MVC geliştiricisi için de geçerli.

Bunlar tamamen ayrı varlıklar değildir ve Microsoft her ikisini de desteklemeye devam ettiği sürece, her biri için karışık bir istisnai geliştirici grubu görmeye devam edeceğinize inanıyorum.

Bunların hepsi, kullandığımız teknolojide uzman olduğumuzu farz ederek kişisel seçim ile ilgili. WebForms tasarım yaklaşımını uzun yıllardır kullanıyorum ve tek dezavantajı, basit bir yaklaşım nedeniyle çoğu insanın geniş yeteneklerini ortaya çıkarmak için zaman ayırmadıkları olduğunu söylemeliyim.

Yakın zamanda bir projeyi tamamlamak için MVC'yi kullandım ve uygulama geliştirmeye (size daha fazla kontrol, temiz URL'ler, SOC vb.) Tasarım yaklaşımını oldukça beğenmeme rağmen, WebForms'ın sağlayabileceği pek bir şey yok. Aslında, jQuery'nin ortaya çıkışı ve bunun WebForms ile (MVC'nin yanı sıra) birlikte çalışması bu argümanları daha az sorun yarattı. Ve insanlar endişelerinin ayrılmasından MVC'nin MVP'ye göre bir avantaj olarak bahsettiği zaman, onlara Nesneye Yönelik programlama hakkında ne kadar bildiklerini ve soyutlama ve polimorfizm ilkelerini ne kadar kullandıklarını soruyorum.

Şu anda her iki teknolojiyi kullanmakta rahatım ve duruma göre seçim yapıyorum. Açıkçası, bu size kalmış, ancak gerçek şu ki, herkes belirli bir teknolojinin neler yapabileceğini derinlemesine öğrenmek için zaman ayırmıyor.

Bir programlama problemiyle karşılaştığımda, cevaplar için sık sık internete bakarım. Webforms, hemen hemen her şey hakkında tonlarca bilgi / bileşen içerir. MVC'de daha az kaynak nedeniyle çevrimiçi ve bir şeyler yapmak için gereken soyutlama katmanları bir zamanlar yapabileceğim şeyler için bir sınır oluşturdu. MVC toplamı, geliştirici olarak verimliliğimi öldürürken, Webform'lar bunu yapmaz. Şimdilik MVC yerini alacak kadar olgunlaşana kadar web formlarına bağlı kalıyorum.

Peki, WebForms daha fazla öğrenme kaynağına sahiptir (sadece daha eski olması nedeniyle) ve bu nedenle “bilinmeyen” yeni programcıların, MVC gibi yeni şeylerin aksine, bu eski teknoloji ile ilgili bilgi bulma olasılıkları daha yüksek olacaktır. .

Üst düzey / deneyimli programcılar daha eskidir ve programda eski programlara göre daha uzun süre programladıkları için eski teknolojide daha usta olacaktır.

Adamlarınızı MVC'de WebForms uygulamalarında olduğu kadar yetkin hale getirmek için harcadığınız para ve çabayı harcayamazsanız, şüphesiz yeni platformda güncellemeyi mümkün olduğunca uzun süre tutamayacaksınız.

Bu yüzden birkaç lojistik problem sunar: MVC'nin faydaları daha düşük kalite ve kullanım süresi açısından maliyeti ağırlıyor mu? Tamamen WebForms'da yazılmış bir sitem varsa, MVC'yi bu siteye entegre etmek için harcayacağınız çabaya değer mi gelir?

Önceki bir yorum yapan tarafından belirtildiği gibi MVC, WebForms ile yapabildiğiniz gibi kontrol cihazı ile aynı arayüz seviyesine ulaşmanızı da önler. Her şeyi “Kullanıcıları bir şeyler doldurmaktan / öğrenmekten sakınmak” yönündeyken, takımların yazdıkları her şey için bu paradigmaya fanatik bir şekilde yapışan bir programı kurması / uygulaması hala makul derecede zahmetli olabilir.

Bence bu iki teknolojinin arasındaki boşluk eskisi kadar geniş değil.

• Web formları, MVC'nin kullandığı yönlendirme motorunu kullanabilir (veya çok benzer bir şey).
• Kod yöneticisi, komut dosyalarını birleştirebilir, bir CDN'den yükleme yapabilir ve hatta komut dosyalarının yüklenmesini geciktirebilir.

Sorunuzu doğrudan cevaplamak için, tercihin ve / veya projenin ne olduğunu düşünüyorum. Her ikisi de kalkınmaya önemli ölçüde farklı bir yaklaşım getiriyor. Şahsen ben MVC'ye doğru ilerlemeye çalışıyorum ama yine de Webformlarla çalışmaktan zevk alıyorum. Bence, her iki teknolojiyi de deneyimleyerek karar vermeniz için MVC veya Webforms kullanmanız gerekip gerekmediğine cevabınız sizin için.