Microsoft'un söylediğini biliyorum
ASP.NET MVC, WebForms'un yerini almaz.
Bazı geliştiriciler WebForms'un geliştirilmesinin MVC'den daha hızlı olduğunu söylüyor. Ancak, kodlama hızının teknoloji ile konfor seviyesine düştüğüne inanıyorum, bu yüzden herhangi bir cevap istemiyorum.
ASP.NET MVC'nin bir geliştiriciye uygulamaları üzerinde daha fazla denetim sağladığı düşünüldüğünde, WebForms neden eski sayılmaz? Alternatif olarak, yeni geliştirme için ne zaman MVC yerine WebForms'u tercih etmeliyim?
Webforms ve MVC şu anda gündemde olan bir konu gibi görünüyor. Tanıdığım herkes MVC'yi bir sonraki harika şey olarak tanıtıyor. İçindeki hafif dabbling'lerimden, tamam görünüyor, ama hayır, web formlarının sonu olacağını sanmıyorum.
Benim akıl yürütmem ve web formlarının neden MVC üzerinden seçileceğinin akıl yürütmesi, birinin diğerinden daha iyi bir şeyden ziyade bir iş perspektifiyle ilgisi var.
Zaman/para, MVC üzerinden web formlarının seçilmesinin en büyük nedenidir.
Ekibinizin çoğu web formlarını biliyorsa ve MVC'de bunları hızlandıracak zamanınız yoksa, üretilecek kod kaliteli olmayabilir. MVC'nin temellerini öğrenmek, sonra atlamak ve yapmanız gereken karmaşık sayfayı yapmak çok farklı şeyler. Öğrenme eğrisi yüksek olduğundan bütçenizi hesaba katmanı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 yapmaya daha eğilimli olabilirsiniz.
Burada ya hep ya hiç bir yaklaşım olduğunu söylemiyorum, ama özellikle takımdaki herkes MVC aşina değilse, her ikisinin bir bölünmesi varsa, kodunu korumak zorlaştırır.
Şirketim kısa süre önce 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üleme ve Düzenleme işlevine sahip olmasıdır. Sayfada birden fazla forma ihtiyaç duyduk. Büyüklük yok, o zamanlar dışında bizim ana sayfamızı kullanmazdık. Hem web formu 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 zorundaydık. Şimdi ekstra bir yuvalama katmanımız var.
Uygun MVC ayrımını izlemesi için bu sayfalar için tamamen yeni bir klasör yapısı oluşturmamız gerekiyordu.
3 sayfa için çok fazla dosya olduğunu hissettim, ama bu benim kişisel görüşüm.
Bence, sitenizi MVC kullanmak için güncellemek için yatırım yapmak için zaman/para yoksa, MVC üzerinden web formları seçersiniz. Buna yarım kollu bir yaklaşım yaparsanız, şu anda sahip olduğunuz web formlarından daha iyi olmayacaktır. Daha da kötüsü, üst yönetim bunu bildiklerinden daha düşük bir şey olarak görebileceğinden, bu teknolojiyi dağınıksa şirketinizdeki başarısızlık için kuruyor olabilirsiniz.
Ben ASP .Net WebForms uygulamaları 3 yıl boyunca geliştirdim ve bir MVC öğretici yaptıktan bir gün sonra satıldı. MVC neredeyse her zaman daha iyi bir çözümdür. Neden?
Yukarıdaki sorunlardan bazılarının WebForms geliştikçe bir dereceye kadar çözüldüğünü biliyorum, ancak bu benim orijinal deneyimimdi. Sonuç olarak, bir proje zaten kullanmadığı sürece WebForms için bir iş vakası bulmak son derece zor bulurdum.
"Farklı müşteriler farklı programlama yaklaşımları arıyor ve WebForms'u çok seviyor ve harika olduğunu düşünüyor. Diğerleri MVC'yi seviyor ve harika olduğunu düşünüyor. Bu yüzden her ikisine de yatırım yapıyoruz."
Yani, bu bana bunun teknik bir sorun olmadığını söylüyor. Eğer daha "yumuşak bir sorun" daha. Kişisel tercihlerden biri. Bu, birkaçınızın söylediği şeyle aynı doğrultuda.
Tüm cevaplar için teşekkürler.
Bu çok cevapları olan eski bir soru ama hiçbiri listelenmesini beklediğim cevap yoktu.
Kısa cevap:
Ancak buna düzgün bir şekilde bakmak için, her birinin tarihini anlamalısınız.
ASP.NET Web Formları, Microsoft'un Visual Basic 6 ActiveX denetimlerini, sunucudaki VB6 DLL'lerini ve ASP Klasik. O sırada web geliştirme kullanarak) dinamik web uygulamaları geliştirenlere yanıttı. ASP.NET Web Forms, Microsoft'un çıktısı olan ve aslında Windows yığınında verimli iş programlaması yapmak için çizim tahtasına geri dönen .NET Framework'ün tamamı ile birlikte, onun günü, şaşırtıcı ve güzel.
Tüm yaklaşım, geliştiricilere Windows uygulama geliştirmeye çok benzer bir şey, ancak internet hizmetlerinin gücü ile her iki dünyanın en iyisini vermekti. Fikir, tıpkı bir VB6/WinForms "Form" (bir pencere) ile aynı şekilde bir web sayfasının bir form olduğu (tıpkı bir pencere gibi, bkz.) ve bu formda VB/WinForms GUI geliştiricilerinin alışkın olduğu etiketleri, metin kutularını, veri ızgaralarını, düğmeleri ve diğer şeyleri sürükleyip bırakabilirsiniz.
Bir düğmenin bir şey yapması için, sürükleyip bıraktıktan sonra, tasarımcıda çift tıklamanız ve kod düzenleyicide olmanız, bu "tıklama" etkinliği gerçekleştiğinde forma ne yapacağınızı söylemeniz yeterlidir. Windows GUI geliştiricilerinin GUI VB6 ve rakip araçları kullanarak yazılımı tam olarak böyle yarattıklarıydı dışında kod sunucuda yürütülüyor! Vaov!
Bu 2002 teknolojisiydi. Zamanında şaşırtıcı ve güzel internet özellikli bir cevap olarak GUI çözümler için RAD geliştirme, gerçekleştirmeleri gereken iş hedeflerine sahip dağınık yazılım geliştiricileri dünyasına bir güç duygusu getirdi.
Ne yazık ki, bu programlama modeli, Windows GUI programlama metaforunu o kadar çok vurgulamaktadır ki, beraberinde gerekli uygulama ayrıntılarının yükünü, olay yaşam döngülerini karşılamak için gerekli tüm hızlandırma bagajını ve basit HTML'nin çirkin ayrıntılarını gizlemektedir. Bu sürükle ve bırak bileşenlerinin ve denetimlerinin çıkardığı komut dosyası. Ve günün sonunda, gerçek uygulamaları destekleyen geliştiriciler kaçınılmaz olarak bu bileşenlerin derinliklerine kazmak veya kendi parçalarını yazmak zorunda kaldılar ve sonuç olarak bu altyapı ile savaşlar, havai yığınlar üzerine kazıkların ardında bırakacak savaşlar, saç çekti ve gözyaşları.
Destek olmak. Ellerinizi yıkayın. İş sorununa tekrar bakalım. İş hedeflerimiz neler?
web uygulamaları oluşturmalı ve yönetmeliyiz. Kısıtlarımız, HTTP, HTML, Javascript ve CSS'de bulunan World Wide Web'e sahip olmamız ve sunucuda iş kuralları, veritabanları ve küçük bir avuç harika programlama dili (örn. C #) var. Geliştirme metodolojimizi yönlendirmek için bu Windows GUI metaforuna gerçekten ihtiyacımız var mı? Neden sadece uygulama sorunlarına odaklanmıyor ve GUI metaforlarını ortadan kaldıramıyoruz?
ASP.NET MVC devreye giriyor. Kendilerini "Alt.Net" olarak adlandıran ve doğru ve saf yazılım geliştirme ilkelerine geri dönmek isteyen geliştiricilerin isyanıyla başladı. Artık muss ve yaygara yok, sadece iş hedeflerine ve en iyi yazılım uygulamalarına odaklanın.
Bunun bu durumda gerçekten ne anlama geldiği:
Javascript'in üst düzey bir programlama dili olduğu gibi HTML'nin zaten çok yüksek bir biçimlendirme dili olduğunu unutmayın. Meclis dili ve C ile uğraşsaydık tüm hikaye farklı olurdu.
O zaman # 2 üzerine genişleyen ASP.NET MVC'nin başka bir hedefi, 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 dayandığı zengin temelden yararlanmasını sağlamaktır. ön uç istemci platformu.
ASP.NET MVC geliştiricilerinin, sunucu tarafı mimarisiyle savaşmadan zengin Javascript kitaplıkları ve istemci tarafı şablonlama tekniklerini kullanarak kendilerini evlerinde hissettiklerini göreceksiniz. Bu, aslında ASP.NET Web Formları için geçerli değildi, çünkü Web Formları, gerçekten yapmak zorundasınız hariç, HTML veya komut dosyasına hiç bakmanızı istemiyor. , dikkat, bu kalp zayıflığı için değil.
Ben ASP.NET MVC tam ve toplam dönüştürmek ve hala çok büyük WebForms uygulamaları korumak zorunda dedi, geri bakmadım. İşte benim almam:
WebForms
Izgaralarla ilgili ağır bir kaldırma yaptığınız zaman bunları kullanın. Tablo denetimlerine güzel bir şekilde uyan basit bir veri kümeniz olduğunda ve kullanıcıların kayıtları güncellemesi için basit bir yol sağlamak istediğinizde ızgara denetimleri gerçekten çok güzel. Evet, MVC 4'ün harika çalışan Ajax liste türü bir şeye sahip olduğunu biliyorum, bu harika çalışıyor, ancak işimizde genellikle dün çalışan bir şey elde etmemiz gerekiyor ve iyi eski moda ızgaralar harika çalışıyor ve kullanıcılar olmaktan mutluluk duyuyor glee ile bir tablo üzerinde sekme yapabiliyor. Benim için bu benim için WebForms ile ilgili en iyi şey; ancak Ryan belirttiği gibi, WebForms büyük bir zaman dağınıklığı olabilir, çünkü şık bir kod arkası dosyasından çitin her iki tarafını oynuyorsunuz. Tüm denetleyici türü öğelerinizi görünümlerinizle karıştırmak aynı anda hem gül hem de diken olabilir.
[~ # ~] MVC [~ # ~]
Bunu gerçekten kendiniz almak istediğinizde kullanın ve bir uygulamayı sıfırdan başlatma şansınız olduğunda. Açıkça tanımlanmış bir MVC uygulamasına sahip olmak başlamak için biraz daha fazla iştir, ancak sürdürülebilirlikteki faydaları ilk kurulum maliyetinden ağır basar. İlginç Ajax etkileşimleri yapmak istiyorsanız, modelinizi temiz URL'ler ve rotalar gibi kodla yazmayı ve uygulamanızın tüm akışını kontrol edebilmeyi tercih ederseniz, bu kesinlikle gitmenin yoludur. İlk başta alışmak biraz zaman alıyor ama bence yeşil alan uygulamaları için daha iyi bir seçenek.
Sonuç olarak, benim için, ızgaralar ve! :)
Benim deneyimim:
Bu deneyimden sonra, web formlarını kullanarak başka bir uygulama yazmaya çalıştım ve yaklaşık bir gün boyunca web formlarının geliştiriciyi html, javascript ve css kullanan bir uygulama geliştirdikleri gerçeğinden nasıl korumaya çalıştığıyla uğraştıktan sonra hayal kırıklığına uğradım.
Daha sonra MVC denedim ve çıktı üzerinde daha doğrudan kontrole sahip (ve CakePHP'den MVC paradigması ile biraz deneyim) Bu basit uygulamayı tam olarak günde yaklaşık 1/2 içinde istediğim şekilde tamamlayabildim.
JQuery gibi güçlü UI çerçevelerinin mevcudiyeti, genellikle hantal önceden oluşturulmuş UI bileşenlerini kullanmak lehine çıktının doğrudan kontrolünden vazgeçme cazibesini ortadan kaldırır.
Web formlarını tercih ediyorum çünkü geçmişim Windows geliştirme.
Developmnt hızı önemli bir konudur, ve ben kolayca bir sayfada formları ile düzeltmek için Hindistan'da birine sorun geçebilir, ayrıca, bir sayfada bir hız sorunu varsa, asp.net hızı hakkında gerçekten iyi bir kitap kullanışlı (Rick Kiessig adamdır).
webforms eski windows insanlar için mvc web insanlar içindir
ancak, Rick'in harika bir kitap yazdığı modern dünyada, sunucuların günlük hızla ve Hindistan'da ucuz kodlayıcıların arttığı webformların Edge'i var
Benim 2 sent seçeneğiniz varsa, her zaman yeni projeler için ASP.NET MVC kullanmaktır. Bence, webforms web uygulamaları geliştirmek için iyi bir yol değil, nokta.
Bence temel soyutlama REST kötü, tüm postback modeli kötü, html/css GUI editörüne güven ile verildiği yol kötü, sihirbazlar ve GUI'ler gibi şeylere vurgu ayar yapmak kötü, URL'ler kötü.
Tüm cevapları okudum ve kişisel deneyimimin yukarıdaki cevaplara bir şey katacağını hissettim.
3-4 yıl önce, Webforms kullanarak 2-3 web sitesi projesi geliştirdim. O zamanlar, MVC etrafta değildi ya da duymadım. Geliştirme doğalydı (daha önce web geliştirme deneyimi olmayan Win-form geliştirmesinden geliyordum) benim için hızlıydı, çünkü detaylarda HTML öğrenmek zorunda değilim ve web kontrolleri çok yardımcı oldu (cehennem çok, hayatı kolaylaştırdı) .
Şimdi, tüm bu zamandan sonra, yakın zamana kadar herhangi bir web projesi çalışma değildi ve sadece WPF kullanarak bazı windows uygulaması bina.
Birkaç gün önce bir web sitesi için bir fikrim vardı ve onu geliştirmeyi düşündüm: MVC'de bu kez (her yerde konuştuklarından beri, ben de öğrenmem gerekiyordu, bu yüzden MVC'yi seçiyorum). Hala öğrenmeye ve inşa etmeye çalıştığım için proje hala geliştirme aşamasında.
Yani, iki b/w bulmak anahtar farklılıklar şunlardır: -
Windows geliştirmeden gelen biri için Web formları her zaman elverişli olacaktır. Windows geliştirici için Asp.net öğrenme eğrisi biraz dik
Başka bir teknolojide web geliştirmeden gelen biri için, MVC, en sonuncusu ile alay ettiği için tercih edilecektir.
İyi HTML ve CSS bilgisine sahipseniz, MVC'de geliştirme daha kolay ve daha temizdir
Dağıtım hala bir sorun. Web formlarında sadece kopyalama ve yapıştırma yapmak gerekiyordu. Ancak, bu bazı şeylerin yapılmasını gerektirir.
Kısacası, her ikisi de bir süre burada kalacak.
Bu konunun henüz bu konuya verilen 15 cevap arasında öne sürdüğünü görmedim, ancak düşünmeye değer olduğunu düşünüyorum.
Deneyimlerime göre Web Formları, MVC'den daha çok Win Forms ve WPF'ye benziyor. Bu göz önüne alındığında, ekibin bu tür bir teknolojide en fazla deneyimi olduğunda veya Web Formları projesi mevcut (veya aynı anda geliştirilen) Win Formları ile aynı veri kümesine bir arayüz sunacağında Web Formlarını seçmeyi düşünebilirim WPF projesi. Bunu yapmak, uygulama mantığı ikisi arasında oldukça benzer olabileceğinden, geliştiricilerin projeler arasında daha kolay geçiş yapmalarını sağlar.
Diğer cevapların işaret ettiği gibi, MVC çerçevesindeki geliştirme, Ruby, PHP, Python vb.) Microsoft muadillerinden daha fazladır; doğal olarak MVC seçimi, ekipler bu alanlarda deneyim ve diğer cevaplarda sunulan faktörler.
Birkaç yıl önce MVC'ye gitmememizin nedeni, Microsoft'tan olgunlaşmamış bir teknolojiydi. Son birkaç yıldır şimdi daha olgun bir versiyondayız (4) ve MS bununla nereye gittiklerini bulmuş gibi görünüyor. Ancak, sürüm 4'te kullanmak istediğimiz özellikler bir Windows 2012 sunucusu gerektirdiğinden (IIS8 üzerinden web soketleri) MVC kullanarak büyük LOB uygulamaları geliştirme konusunda hala isteksiziz. 1 yıl içinde MVC'yi daha fazla kabul edeceğimizi umuyorum çünkü umarım daha fazla üçüncü taraf kontrolü mevcut olacak, teknoloji yerleşmiş olacak ve bunu destekleyecek altyapıya sahip olacağız.
Bu karar tercihlerinize, taleplerinize ve hatta bilgi ve deneyiminize bağlıdır.
MVC öğrenmek için eğitim veya bir teslim alma zamanı. Bütün bunlar bir veya başka bir yaklaşım seçmek için önemlidir.
Biri diğerinden daha iyi değil, sadece hem yaklaşım hem de çerçevelerin artıları ve eksileri var.
Kişisel olarak MVC 3'ü tercih ediyorum, kendi deneyiminizi almanızı tavsiye ederim, 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'u seçmemizin tek nedeni, MVC'den WebForms için çok daha fazla 3. taraf UI denetime sahip olmanızdır. MVC'yi seçiyorum çünkü WebForms ile çok çalıştım ve yeni/yeni bir şeyle çalışmak istiyorum, ancak yine de MS mağazasından :)
Temel olarak, hiçbir şey WebForms'da görünüm durumunu kapatmanızı ve Model bağlama ve sunucu tarafı denetimleri yerine döngüler ve if/for döngülerini kullanmanızı engellemez.
Bu WebForms mu yoksa MVC kodu mu:
<% foreach (var item in Model.Items) { %> <p><%: item.Name %></p> <% } %>
WebForms'ta bulduğum tek sınırlama, Bağımlılık Enjeksiyonu/Denetimi Ters Çevirme kullanıyorsanız, WebForms sayfalarının parametresiz yapıcıya sahip olması gerektiğinden yapıcı enjeksiyonuna sahip olamayacağınızdır, bu nedenle özellik enjeksiyonunu kullanmanız gerekir. Bu gerçekten çok mu önemli?
Bana göre, bunlar yeterince ilişkilidir ve tercih edilmesi gereken kabaca aynı özelliklere sahiptir.
Harika bir WebForms geliştiricisi, harika bir MVC geliştiricisi kadar güçlü bir ürün üretebilir. Ancak kendisini MVC'yi benimsemeye zorlayan büyük WebForms geliştiricisi kısa sürede ortaya çıkacak. Aynı şey WebForms'u denemek için 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 grup olağanüstü geliştirici görmeye devam edeceğinize inanıyorum.
ASP.NET MVC gerçekten Ruby ve yeni, modaya uygun ve (IMO) tarayıcı (istemci) sunucudan mümkün olduğunca ayrıştırmanın daha iyi bir yoludur.
ASP.NET Webforms hemen hemen her şeye doğrudan erişim ile sunucu tarafında istemci üzerinde çok fazla kontrol sağlar. Temelde görüşünüz ve kontrol cihazınız aynıdır, bu da size çok fazla güç ve çoğu zaman çok fazla karışıklık verir.
ASP.NET MVC, görünümü.
Temel olarak, fark işleme verilerini görüntüleme dosyasına (= = --- ==) görüntülemek ve iş mantığını ve geri kalanını bırakmak denetleyicide, her iki kural ile daha temiz tutmak, ama aynı zamanda birbirlerine webforms daha az erişim sağlar.
WebForms daha fazla öğrenme kaynağına sahiptir (sadece daha eski olması nedeniyle) ve bu nedenle "bilinmeyen" yeni programcıların MVC gibi daha yeni şeylerin aksine bu eski teknoloji hakkında bilgi bulma olasılığı daha yüksektir. .
Kıdemli/deneyimli programcılar daha eskidir ve daha yeni programda olduğundan daha uzun programladıkları için eski teknolojide daha yetkin olacaktır.
WebForms uygulamalarında olduğu gibi MVC'de yetkin hale gelmek için para ve çaba harcayacağınız sürece, şüphesiz yeni platforma yükseltmeyi mümkün olduğunca uzun süre denemeye devam edeceksiniz.
Bu yüzden çeşitli lojistik problemler ortaya koyuyor: MVC'nin faydaları daha düşük kalite ve kurulum süresi açısından maliyetten daha ağır mı? Tamamen WebForms'ta yazılmış bir sitem varsa, MVC'yi bu siteye entegre etmek için çaba ve paraya değer mi?
Önceki bir yorumcunun belirttiği gibi, MVC aynı zamanda WebForms ile yapabileceğiniz gibi denetleyici ile aynı düzeyde arayüz elde etmenizi önler. Her şeyi "Kullanıcıyı bir şeyleri doldurmaktan/öğrenmekten uzak tutun" yönündeyken, ekiplerin yazdıkları her şey için fanatik olarak bu paradigmaya yapışan bir programı dağıtmaları/uygulamaları mantıksız olabilir.
Hepimiz kullandığımız teknolojide yetkin olduğumuzu varsayarak, kişisel seçim ile ilgilidir. WebForms tasarım yaklaşımını uzun yıllardır kullanıyorum ve tek dezavantajı, basit bir yaklaşım nedeniyle, birçok insanın geniş yeteneklerini ortaya çıkarmak için zaman ayırmadığını 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 sevsem de, WebForms'un sağlayamayacağı pek bir şey yok. Aslında, jQuery'nin ortaya çıkışı ve WebForms (MVC'nin yanı sıra) ile çalışmaları bu argümanları daha az sorun haline getirmiştir. Ve insanlar MVC'nin MVP'ye karşı bir avantaj olarak endişelerin ayrılması hakkında konuştuğunda, onlara Nesne Odaklı programlama hakkında ne kadar bildiklerini ve soyutlama ve polimorfizm ilkesini ne kadar kullandıklarını soruyorum.
Şu anda her iki teknolojiyi kullanmakta rahatım ve duruma göre seçip seçiyorum. Açıkçası, size kalmış, ama gerçek şu ki, herkes belirli bir teknolojinin neler yapabileceğini derinlemesine öğrenmek için zaman ayırmıyor.
Bir programlama problemiyle karşı karşıya kaldığımda genellikle cevaplar için internete bakarım. Webforms, hemen hemen her şeyi yapmak için tonlarca bilgi/bileşene sahiptir. MVC'de çevrimiçi olarak daha az kaynak ve bir şeylerin çalışması için gereken soyutlama katmanları nedeniyle bir zamanlar yapabileceğim şeylere bir sınır koydu. MVC total bir geliştirici olarak verimliliğimi öldürürken Webforms ile değil. Şimdilik, MVC'nin yerini alacak kadar olgunlaşana kadar web formlarına bağlı kalıyorum.