Yanımda kimse sadece ASP.NET MVC alamıyor mu? [kapalı]

CTP'den beri ASP.NET MVC ile uğraşıyorum ve yaptıklarını çok seviyorum, ama alamadım şeyler var.

Örneğin, beta1'i indirdim ve onunla birlikte küçük bir kişisel site / özgeçmiş / blog oluşturuyorum. ViewSinglePost görünümünden bir pasaj:

 <%
        // Display the "Next and Previous" links
        if (ViewData.Model.PreviousPost != null || ViewData.Model.NextPost != null)
        {
            %> <div> <%

            if (ViewData.Model.PreviousPost != null)
            {
                %> <span style="float: left;"> <%
                    Response.Write(Html.ActionLink("<< " + ViewData.Model.PreviousPost.Subject, "view", new { id = ViewData.Model.PreviousPost.Id }));
                %> </span> <%
            }

            if (ViewData.Model.NextPost != null)
            {
                %> <span style="float: right;"> <%
                    Response.Write(Html.ActionLink(ViewData.Model.NextPost.Subject + " >>", "view", new { id = ViewData.Model.NextPost.Id }));
                %> </span> <%
            }
            %>
                   <div style="clear: both;" />
               </div> <%
        }
    %>

İğrenç! (Ayrıca HTML geçici yer tutucu HTML olduğunu unutmayın, işlevsellik çalıştıktan sonra gerçek bir tasarım yapacağım) .

Yanlış bir şey mi yapıyorum? Çünkü klasik ASP'de çok karanlık günler geçirdim ve bu etiket çorbası bana bunu hatırlatıyor.

Herkes nasıl daha temiz HTML yapabileceğinizi vaaz ediyor. Bil bakalım ne oldu? Tüm kullanıcıların% 1'i çıktı HTML'ye bakar. Bana göre, bakımı kolay olan kodum olduğu sürece Webforms'un oluşturulan HTML'deki girintimi bozup bozmadığını umursamıyorum ... Bu değil!

Öyleyse, beni dönüştür, çok zor bir web formu adamım, bunun için neden güzel biçimlendirilmiş ASPX sayfalarımı bırakmalıyım?

Düzenleme: İnsanlar bu konuda stfu olur "temp Html / css" satır kalın.

Web Formları ile karşılaştırıldığında, MVC, sayfa çıktısı üzerinde daha fazla kontrole ve daha üst düzey, daha mimari güdümlü bir yaklaşıma sahip HTML üretimine eş zamanlı olarak daha düşük seviyeli bir yaklaşımdır. Web Formlarını ve MVC'yi yakalayayım ve neden bazı klasik Web Formları tuzaklarına düşmediğiniz sürece karşılaştırmanın birçok durumda Web Formlarını tercih ettiğini düşündüğümü göstereyim.

Web Formları

Web Formları modelinde, sayfalarınız doğrudan tarayıcıdan gelen sayfa isteğine karşılık gelir. Bu nedenle, bir kullanıcıyı Kitaplar listesine yönlendiriyorsanız, büyük olasılıkla "Booklist.aspx" adlı bir yerde onu yönlendireceğiniz bir sayfanız olur. Bu sayfada, listeyi göstermek için gereken her şeyi sağlamanız gerekir. Buna veri çekme, herhangi bir iş mantığı uygulama ve sonuçları görüntüleme kodu da dahildir. Sayfayı etkileyen herhangi bir mimari veya yönlendirme mantığı varsa, sayfadaki mimari mantığı da kodlamanız gerekir. İyi Web Formları geliştirme genellikle ayrı (birim-test edilebilir) bir DLL dosyasında bir dizi destekleyici sınıfın geliştirilmesini içerir. Bu sınıf (lar) iş mantığı, veri erişimi ve mimari / yönlendirme kararlarını ele alacaktır.

MVC

MVC, web uygulaması geliştirmenin daha "mimari" bir görünümünü alır: üzerine inşa edilecek standart bir iskele sunar. Ayrıca, yerleşik mimari içinde model, görünüm ve denetleyici sınıflarını otomatik olarak oluşturmak için araçlar sağlar. Örneğin, hem Ruby on Rails (sadece buradan "Rails") ve ASP.NET MVC'de her zaman genel web uygulama mimarisi modellerini yansıtan bir dizin yapısı ile başlayacaksınız. Bir görünüm, model ve denetleyici eklemek için Rails'in "Rails komut dosyası / yapı iskelesi {modelname}" gibi bir komut kullanırsınız (ASP.NET MVC, IDE'de benzer komutlar sunar). Ortaya çıkan denetleyici sınıfında, Dizin (listeyi göster), Göster, Yeni ve Düzenle ve Yok Et (en azından Rails'te, MVC benzerdir) için yöntemler ("Eylemler") olacaktır. Varsayılan olarak, bunlar "

MVC'de dizinlerin ve dosyaların düzeni önemlidir. Örneğin, ASP.NET MVC'de, "Kitap" nesnesinin Dizin yönteminin büyük olasılıkla tek bir satırı olacaktır: "Return View ();" MVC'nin büyüsü sayesinde bu, Kitap modelini Kitapları görüntülemek için kod bulacağınız "/View/Books/Index.aspx" sayfasına gönderir. Rails yaklaşımı benzer, ancak mantık biraz daha açık ve daha az "sihir". Bir MVC uygulamasındaki bir Görünüm sayfası genellikle bir Web Formları sayfasından daha kolaydır, çünkü yönlendirme, iş mantığı veya veri işleme hakkında endişelenmek zorunda kalmazlar.

karşılaştırma

MVC'nin avantajları, endişelerin temiz bir şekilde ayrılması ve çıktınızı üretmek için daha temiz, daha HTML / CSS / AJAX / Javascript merkezli bir model etrafında dönmektedir. Bu, test edilebilirliği artırır, daha standartlaştırılmış bir tasarım sağlar ve daha "Web 2.0" türünde bir web sitesine kapı açar.

Bununla birlikte, bazı önemli dezavantajlar da vardır.

Birincisi, bir demo sitesini çalıştırmak kolay olsa da, genel mimari modelin önemli bir öğrenme eğrisi vardır. "Konfigürasyon Üzerinden Konvansiyon" dediklerinde kulağa hoş geliyor - öğrenecek bir kitabın konvansiyonuna sahip olduğunuzu anlayana kadar. Ayrıca, sen çünkü ne olup bittiğini anlamaya biraz çıldırtıcı genellikle edilmektedir açık çağrılar yerine büyü güvenerek. Örneğin, "Dönüş Görünümü ();" yukarıdaki çağrı? Aynı çağrı diğer İşlemlerde de bulunabilir, ancak farklı yerlere giderler. Eğer anlamak MVC kongreo zaman bunun neden yapıldığını biliyorsun. Ancak, kesinlikle iyi bir adlandırma veya kolayca anlaşılabilir kod örneği olarak nitelendirilmez ve yeni geliştiricilerin Web Formlarından daha fazla alması çok daha zordur (bu sadece fikir değildir: Geçen yıl bir yaz stajyeri öğrenmiştim ve MVC bu yıl ve verimlilik farklılıkları - Web Formları lehine telaffuz edildi). BTW, Rails, bu konuda biraz daha iyidir, ancak Ruby on Rails, ciddi şekilde alışmak için dinamik olarak adlandırılmış yöntemlere sahiptir.

İkinci olarak, MVC dolaylı olarak klasik bir CRUD tarzı web sitesi oluşturduğunuzu varsayar. Mimari kararlar ve özellikle kod üreteçleri, bu tür bir web uygulamasını desteklemek için oluşturulmuştur. Bir CRUD uygulaması oluşturuyorsanız ve kanıtlanmış bir mimariyi benimsemek istiyorsanız (veya mimari tasarımdan hoşlanmıyorsanız), muhtemelen MVC'yi düşünmelisiniz. Bununla birlikte, CRUD'dan daha fazlasını yapacaksanız ve / veya mimariyle makul derecede yetkinseniz, MVC, temel yönlendirme modelinde (bir WebForms uygulamasında yönlendirmekten çok daha karmaşık olan) gerçekten ustalaşana kadar bir düz ceket gibi hissedebilir. O zaman bile, her zaman modelle savaştığımı ve beklenmedik sonuçlardan endişe duyduğumu hissettim.

Üçüncüsü, Linq ile ilgilenmiyorsanız (Linq-to-SQL'in kaybolacağından korktuğunuz için veya Linq-to-Entities'i gülünç bir şekilde aşırı üretildiğini ve güç altında bulunduğunu düşünüyorsanız) ASP.NET MVC iskele araçları Linq etrafında inşa beri bu yolu yürümek için (bu benim için katil oldu). Rails'in veri modeli, SQL'de deneyimli olmanız durumunda (ve özellikle TSQL ve saklı yordamlar konusunda bilgili iseniz) elde edebileceğinize kıyasla oldukça beceriksizdir.

Dördüncüsü, MVC taraftarları genellikle MVC görünümlerinin web'in HTML / CSS / AJAX modeline daha yakın olduğunu belirtir. Örneğin, "HTML Helpers" - vew sayfanızda içeriği değiştiren ve HTML denetimlerine yerleştiren küçük kod çağrıları - Javascript ile entegre edilmesi Web Formları denetimlerinden çok daha kolaydır. Ancak, ASP.NET 4.0 denetimlerinizi adlandırma yeteneği sunar ve bu nedenle bu avantajı büyük ölçüde ortadan kaldırır.

Beşinci olarak, MVC puristleri genellikle Viewstate'i deride tutarlar. Bazı durumlarda bunu yapma hakkı vardır. Bununla birlikte, Viewstate ayrıca harika bir araç ve üretkenlik için bir nimet olabilir. Karşılaştırma yapmak gerekirse, Viewstate'i kullanmak, bir üçüncü taraf web kontrollerini bir MVC uygulamasına entegre etmeye çalışmaktan çok daha kolaydır. MVC için kontrol entegrasyonu daha kolay olabilirken, gördüğüm tüm mevcut çabalar, bu kontrolleri görünümün Controller sınıfına (yani - MVC modeli etrafında çalışmak için) geri bağlamak için kod oluşturma ihtiyacından muzdariptir. ).

Sonuçlar

Ben MVC geliştirme birçok şekilde seviyorum (Rails ASP.NET MVC uzun bir atış için tercih rağmen). Ayrıca ASP.NET MVC'nin ASP.NET Web Formlarının bir "anti-desen" olduğunu düşünme tuzağına düşmemizin önemli olduğunu düşünüyorum. Onlar farklı ama tamamen yabancı değil ve kesinlikle her ikisi için de yer var.

Ancak, Web Formları geliştirmeyi tercih ediyorum çünkü çoğu görev için işleri halletmek daha kolaydır (istisna bir dizi CRUD formunun oluşturulmasıdır). MVC ayrıca bir ölçüde teorinin fazlalığından muzdarip gibi görünüyor . Gerçekten de, burada sayfa yönelimli ASP.NET bilen ama MVC deneyen insanlar tarafından SO üzerinde sorulan birçok sorulara bakın. İstisnasız, geliştiriciler çemberlerden geçmeden veya büyük bir öğrenme eğrisine dayanmadan temel görevleri yapamayacaklarını fark ettikçe dişlerin çok fazla gıcırdaması var. Bu kitabımda MVC üstün Web Formları kılan: MVC bir ödeme yapar gerçek dünya fiyatı veya daha kötüsü biraz daha test edilebilir kazanmak için basitçe görülecek serin kullandığınız çünküson teknoloji.

Güncelleme: Yorumlar bölümünde ağır eleştirildim - bazıları oldukça adil. Böylece, sadece bir sonraki büyük şeyde gerçekten eksik olmadığımdan emin olmak için birkaç ay geçirdim Rails ve ASP.NET MVC öğrenmek! Tabii ki, aynı zamanda soruya dengeli ve uygun bir cevap vermemi de sağlıyor. Yukarıdaki yanıtın, yorumların eşzamanlı görünmemesi durumunda ilk cevabımın büyük bir yeniden yazımı olduğunu bilmelisiniz.

MVC'ye daha yakından bakarken, bir süre için büyük bir mea culpa ile sonuçlanacağımı düşündüm. Sonunda, Web Formları mimarisine ve test edilebilirliğine çok daha fazla enerji harcamamız gerektiğini düşünürken, MVC'nin benim için çağrıya gerçekten cevap vermediği sonucuna vardım. Yani, ilk cevabımı akıllıca eleştiren insanlara içten bir "teşekkür ederim".

Bunu dini bir savaş olarak gören ve acımasızca aşağıdan gelen sel baskınları yapanlara gelince, neden rahatsız ettiğinizi anlamıyorum (birkaç kez birbirinden birkaç saniye içinde 20'den fazla oy kullanmak kesinlikle normal değildir). Bu cevabı okuyorsanız ve puanın diğer cevaplardan çok daha düşük olduğu düşünüldüğünde cevabımda gerçekten "yanlış" bir şey olup olmadığını merak ediyorsanız, genel anlamda topluluk (genel olarak, bu 100 defadan fazla oy kullanıldı).

Gerçek şu ki, birçok geliştirici MVC'yi umursamıyor ve aslında bu bir azınlık görüşü değil (blogların belirttiği gibi MS içinde bile).

MVC, çıktılarınız üzerinde daha fazla kontrol sağlar ve bu kontrol ile kötü tasarlanmış HTML, etiket çorbası vb.

Ama aynı zamanda, daha önce sahip olmadığınız birkaç yeni seçeneğiniz var ...

1. Sayfa ve sayfa içindeki öğeler üzerinde daha fazla kontrol
2. Çıktınızda daha az "önemsiz", ViewState veya öğeler üzerinde aşırı uzun kimlikler (beni yanlış anlamayın, ViewState'i beğendim)
3. Javascript ile istemci tarafı programlama yapmak için daha iyi bir yetenek (Web 2.0 Uygulamaları kimse var mı?)
4. Sadece MVC değil, JsonResult kaygan ...

Şimdi bu, WebForms ile bunlardan hiçbirini yapamayacağınız anlamına gelmez, ancak MVC bunu kolaylaştırır.

WebForms'u hızlı bir şekilde bir web uygulaması oluşturmam gerektiğinde kullanıyorum, çünkü sunucu denetimlerinden vb. Yararlanabilirim. WebForms, giriş etiketlerinin ve gönderme düğmelerinin tüm ayrıntılarını gizler.

Dikkatsizseniz, hem WebForms hem de MVC mutlak çöp kapasitesine sahiptir. Her zaman olduğu gibi, dikkatli planlama ve iyi düşünülmüş tasarım, MVC veya WebForms olsun, kaliteli bir uygulama ile sonuçlanacaktır.

[Güncelleme]

Herhangi bir teselli ise, MVC sadece Microsoft'un yeni, gelişen bir teknolojisidir. WebForms'un sadece kalacak değil, aynı zamanda geliştirilmeye devam edeceği birçok yayın var ...

http://haacked.com

http://www.misfitgeek.com

http://rachelappel.com

... ve bunun gibi...

MVC'nin izlediği yol hakkında endişe duyanlar için, "beyler" hakkında görüşlerinizi belirtmenizi öneririm. Şimdiye kadar dinliyor gibi görünüyorlar!

ASP.NET MVC'ye yapılan itirazların çoğu, mimarideki en "isteğe bağlı" ve modüler bitlerden biri olan görünümler etrafında merkezlenmiş gibi görünüyor. NVelocity , NHaml , Spark , XSLT ve diğer görünüm motorları kolayca değiştirilebilir (ve her sürümde daha kolay hale geliyor). Bunların birçoğu sunum mantığı ve biçimlendirmesi yapmak için ÇOK daha özlü sözdizimine sahipken, yayılan HTML üzerinde tam kontrol sağlar.

Bunun ötesinde, hemen hemen her eleştiri varsayılan görünümlerde <%%> etiketine ve bunun ne kadar "çirkin" olduğu anlaşılıyor. Bu görüş genellikle, klasik ASP çirkinliğinin çoğunu kodun arkasındaki dosyaya taşıyan WebForms yaklaşımına alışmaktan kaynaklanır.

Kod-behinds "yanlış" yapmadan bile, Repeaters içinde OnItemDataBound gibi şeyleri var, sadece farklı bir şekilde, "etiket çorbası" daha estetik olarak çirkin. Özellikle diğer ASP.NET olmayan teknolojilerden MVC'ye gelirseniz, bu döngünün çıktısına değişken gömme olsa bile, bir foreach döngüsünü okumak çok daha kolay olabilir. Foreach döngüsünü anlamak, yineleyicinizdeki bir alanı değiştirmenin yolunun OnItemDataBound (ve farenin değiştirilecek doğru öğe olup olmadığını kontrol etme yuvası) ile uğraşmak olduğunu anlamaktan daha az zaman alır.

ASP etiketi-çorba güdümlü "spagetti" ile ilgili en büyük sorun daha HTML arasında veritabanı bağlantıları gibi şeyler itmek oldu.

Bunu <%%> kullanarak yapmak sadece nedensel değil klasik ASP'nin spagetti doğası ile bir korelasyon. Görünüm mantığınızı HTML / CSS / Javascript ve sunum yapmak için gereken minimum mantıkta tutarsanız , geri kalanı sözdizimidir.

Belirli bir işlevsellik parçasını WebForms ile karşılaştırırken, MVC çözümünün gerçekten çok daha basit olmadığından emin olmak için tasarımcı tarafından oluşturulan tüm C # ve arkasındaki kodu #aspx koduyla birlikte eklediğinizden emin olun. .

Sunum mantığının tekrarlanabilir parçaları için kısmi görünümlerin mantıklı kullanımı ile birleştirildiğinde, gerçekten güzel ve zarif olabilir.

Kişisel olarak, erken öğretici içeriğin çoğunun, sadece test odaklı, kontrolün ters çevrilmesi vb. "tag çorbası" na itiraz etmek.

Ne olursa olsun, bu hala beta aşamasında olan bir platformdur. Buna rağmen, WAY daha fazla dağıtım ve Microsoft dışındaki geliştiricilerin çoğu Microsoft-beta teknolojisinden daha fazla gerçek şeyler oluşturuyor. Bu nedenle, vızıltı, etrafındaki altyapıdan (dokümantasyon, rehberlik desenleri, vb.) Daha ileride gibi görünme eğilimindedir. Bu noktada gerçekten kullanılabilir olması sadece bu etkiyi arttırıyor.

<% if (Model.PreviousPost || Model.NextPost) { %>
    <div class="pager">
        <% if (Model.PreviousPost) { %>
            <span><% Html.ActionLink("<< " + Model.PreviousPost.Subject, "view")); %></span>
        <% } if (Model.NextPost) { %>
            <span><% Html.ActionLink(Model.NextPost.Subject + " >>", "view")); %></span>
        <% } %>
    </div>
<% } %>

Katıştırılmış CSS'yi eklemeden bunu nasıl yapacağınızı soran başka bir yayın yapabilirsiniz.

Not: ViewData.Model sonraki sürümde Model olur.

Ve bir kullanıcı kontrolünün yardımıyla bu,

<% Html.RenderPartial("Pager", Model.PagerData) %>

burada PagerData, eylem işleyicisindeki anonim bir kurucu aracılığıyla başlatılır.

edit: WebForm uygulamanızın bu sorun için nasıl görüneceğini merak ediyorum.

Hangi noktada insanların kodları hakkında bakım durdu emin değilim.

HTML, çalışmanızın en genel ekranıdır, çok sayıda web sitesi oluşturmak için not defteri, not defteri ++ ve diğer düz metin editörlerini kullanan bir çok geliştirici vardır.

MVC, web formlarından kontrolü geri almak, durumsuz bir ortamda çalışmak ve Model Görünümü Denetleyici tasarım desenini, normalde bu modelin uygulanmasında gerçekleşen tüm ekstra çalışmalar olmadan uygulamakla ilgilidir.

Kontrol etmek, kodu temizlemek ve MVC tasarım desenlerini kullanmak istiyorsanız, bu sizin için, işaretleme ile çalışmaktan hoşlanmıyorsanız, işaretlemenizin ne kadar hatalı biçimlendirildiğini umursamayın, ardından ASP.Net Web Formlarını kullanın.

İkisinden de hoşlanmıyorsanız, kesinlikle işaretlemede çok fazla iş yapacaksınız.

EDIT I Ayrıca, Web Formları ve MVC'nin yerlerini aldığını belirtmeliyim, hiçbir şekilde birinin diğerinden daha iyi olduğunu, sadece her MVC'nin işaretleme üzerinde kontrolü yeniden kazanma gücüne sahip olduğunu belirtmedim.

Bazı şeyleri kaçırdığını düşünüyorum. İlk olarak, Response.Write öğesine gerek yoktur, <%= %>etiketleri kullanabilirsiniz . İkinci olarak, ortak eylemler yapmak için kendi HtmlHelper uzantılarınızı yazabilirsiniz. Üçüncü olarak, biraz biçimlendirme çok yardımcı olur. Dördüncüsü, tüm bunlar muhtemelen birkaç farklı görünüm arasında paylaşılmak üzere bir kullanıcı kontrolünde sıkışır ve bu nedenle ana görünümdeki genel işaret daha temizdir.

İşaretlemenin hala istediğiniz kadar düzgün olmadığını söyleyeceğim, ancak bazı geçici değişkenlerin kullanılmasıyla önemli ölçüde temizlenebilir.

Şimdi, bu o kadar da kötü değil ve SO için biçimlendirmek zorunda kalmazsam daha da iyi olurdu.

 <%
    var PreviousPost = ViewData.Model.PreviousPost;
    var NextPost = ViewData.Model.NextPost;

    // Display the "Next and Previous" links
    if (PreviousPost != null || NextPost != null)
    {
  %>

 <div>

        <%= PreviousPost == null
                ? string.Empty
                : Html.ActionLinkSpan("<< " + PreviousPost.Subject,
                                "view",
                                new { id = PreviousPost.Id },
                                new { style = "float: left;" } ) %>
          <%= NextPost == null
                ? string.Empty
                : Html.ActionLinkSpan( NextPost.Subject + " >>",
                                   "view",
                                    new { id = NextPost.Id },
                                    new { style = "float: right;" } ) %>

  <div style="clear: both;" />
  </div>

  <% } %>

MVC ile önemli olan uzun zamandır var olan kavramsal bir çerçevedir ve hem yatay hem de dikey olarak ölçeklenen hem web uygulamaları hem de iş istasyonu uygulamaları oluşturmanın verimli ve güçlü bir yolu olduğunu kanıtlamıştır. Doğrudan Alto ve Smalltalk'a geri döner. Microsoft partiye geç kaldı. ASP.NET MVC ile sahip olduğumuz şey gerçekten ilkel, çünkü yapacak çok şey var; ama lanet olsun, hızlı ve öfkeli bir şekilde yeni sürümler çıkarıyorlar.

Ruby on Rails ile olan büyük anlaşma neydi? Raylar MVC'dir. Geliştiriciler dönüşüm yapıyor çünkü ağızdan ağıza göre programcıların üretken olmasının yolu haline geldi.

Bu çok büyük bir anlaşma; MVC ve jQuery'nin örtük olarak onaylanması, Microsoft'un platformdan bağımsız olarak kritik önem taşıdığını kabul ettikleri için önemli noktalar. Ve bununla ilgili tarafsız olan şey, Web Formlarının aksine, Microsoft'un sizi kavramsal olarak kilitleyememesidir. Tüm C # kodunuzu alabilir ve tamamen başka bir dilde yeniden ekleyebilirsiniz (PHP veya java diyelim), çünkü kodun kendisi değil taşınabilir olan MVC kavramıdır. (Ve tasarımınızı alıp küçük kod değişikliği olan ve tasarım değişikliği olmayan bir iş istasyonu uygulaması olarak uygulamanızın ne kadar büyük olduğunu düşünün. Web Formları ile deneyin.)

Microsoft, Web Formlarının bir sonraki VB6 olmayacağına karar verdi.

Lütfen Rob Conery'nin mesajına bir göz atın I Spose I Just Say It: You You Learn MVC

ASP.NET MVC çerçevesinin web formlarına göre iki ana avantajı:

1. TestedilebilirlikTest - Kullanıcı arayüzü ve web formlarındaki olayların test edilmesi imkansızdır. ASP.NET MVC ile, birim test denetleyicisi eylemleri ve oluşturdukları görünümler kolaydır. Bu, ön geliştirme maliyetinde bir maliyetle birlikte gelir, ancak çalışmalar, uygulamayı yeniden düzenleme ve sürdürme zamanı geldiğinde uzun vadede işe yaradığını göstermiştir.
2. Oluşturulan HTML üzerinde daha iyi kontrol - Oluşturulan HTML'yi umursamadığınızı belirtirsiniz, çünkü kimse ona bakmaz. Bu, HTML'yi düzgün biçimlendirmenin tek nedeni olsaydı geçerli bir şikayettir. Düzgün biçimlendirilmiş HTML istemek için sayısız neden vardır: SEO, kimlik seçicileri daha sık kullanma (css ve javascript'te), görünüm durumu eksikliği ve gülünç derecede uzun kimlikler (ctl00_etcetcetc) nedeniyle daha küçük sayfa ayak izleri.

Şimdi, bu nedenler ASP.NET MVC'yi siyah beyaz bir şekilde web formlarından daha iyi veya kötü yapmaz. ASP.NET MVC, web formlarında olduğu gibi güçlü ve zayıf yönlerine sahiptir. Bununla birlikte, ASP.NET MVC ile ilgili şikayetlerin çoğu, çerçevedeki gerçek kusurlardan ziyade nasıl kullanılacağı konusunda bir anlayış eksikliğinden kaynaklanıyor gibi görünmektedir. Kodunuzun doğru hissetmemesinin veya doğru görünmemesinin nedeni, kemeriniz altında birkaç yıllık web formları deneyimine ve yalnızca 1-2 aylık ASP.NET MVC deneyimine sahip olmanız olabilir.

Buradaki problem o kadar da değil, ASP.NET MVC sallanıyor veya berbat, bu yeni ve doğru bir şekilde nasıl kullanılacağı konusunda çok az anlaşma var. ASP.NET MVC, uygulamanızda olup bitenler üzerinde çok daha ayrıntılı denetim sunar. Bu, belirli görevleri onlara nasıl yaklaştığınıza bağlı olarak daha kolay veya daha zor hale getirebilir.

Hey, ben de MVC'ye geçmekte zorlanıyordum. Kesinlikle klasik ASP ve MVC render hayranı değilim bana o günlerin çok hatırlatıyor. Ancak, MVC'yi ne kadar çok kullanırsam, o kadar fazla büyür. Ben bir webforms adamım (birçok olduğu gibi) ve datagrids, vb ile çalışmaya alışmak geçen birkaç yıl geçirdim MVC ile götürülür. Cevap HTML Yardımcı sınıflarıdır.

Geçenlerde MVC bir "ızgara" sayfalama eklemek için en iyi yolu anlamaya çalışırken 2 gün geçirdim. Şimdi, web formları ile bunu hemen halledebilirim. Ama şunu söyleyeceğim ... MVC için disk belleği yardımcı sınıfları oluşturduktan sonra uygulaması son derece basit hale geldi. Bana göre, web formlarından bile daha kolay.

Olduğu söyleniyor, ben orada HTML Helpers tutarlı bir dizi olduğunda MVC çok daha geliştirici dostu olacağını düşünüyorum. Yakın gelecekte web üzerinde bir ton HTML yardımcı sınıfının açıldığını görmeye başlayacağımızı düşünüyorum.

Komik çünkü web formlarını ilk gördüğümde bunu söyledim.

Henüz asp.net MVC almadığımı itiraf edeceğim. Yaptığım bir yan projede kullanmaya çalışıyorum ama oldukça yavaş gidiyor.

Web formlarında yapması çok kolay olan şeyleri yapamamanın yanı sıra etiket çorbasını da farkettim. Gerçekten bu açıdan geriye doğru bir adım atıyor gibi görünüyor. Öğrenirken daha da iyi olacağını umuyorum.

Şimdiye kadar MVC'yi kullanmanın en önemli nedeninin HTML'niz üzerinde tam kontrol elde etmek olduğunu fark ettim. Ayrıca asp.net MVC web formlarından daha hızlı daha fazla sayfa sunabiliyor ve muhtemelen bununla ilgili okudum, bireysel sayfa boyutu ortalama bir web form sayfasından daha küçük.

Büyük tarayıcılarda çalıştığı sürece HTML'imin nasıl göründüğü umurumda değil, ancak sayfalarımın ne kadar hızlı yüklendiğini ve ne kadar bant genişliği aldıklarını önemsiyorum.

Ben tamamen bu çirkin biçimlendirme olduğunu kabul ederken, ben bir bütün olarak ASP.NET MVC yazmak için çirkin görünüm sözdizimi kullanarak adil olmadığını düşünüyorum. Görünüm sözdizimi Microsoft'un en az dikkatini çekti ve yakında bu konuda yapılacak bir şey bekliyorum.

Diğer cevaplar MVC'nin bir bütün olarak faydalarını tartıştı, bu yüzden görünüm sözdizimine odaklanacağım:

Html.ActionLink ve HTML üreten diğer yöntemleri kullanmaya teşvik etmek yanlış yönde atılmış bir adımdır. Bu, sunucu kontrollerinin şapırtıları ve benim için var olmayan bir sorunu çözüyor. Koddan etiketler oluşturacaksak, neden HTML kullanmaktan rahatsız oluyorsunuz? Sadece DOM veya başka bir model kullanabilir ve içeriğimizi denetleyicide oluşturabiliriz. Tamam, kulağa kötü geliyor, değil mi? Ah evet, endişelerin ayrılması, bu yüzden bir görüşümüz var.

Ben doğru yön görünümü sözdizimi mümkün olduğunca HTML gibi yapmak olduğunu düşünüyorum. Unutmayın, iyi tasarlanmış bir MVC sadece kodun içerikten ayrılmasını sağlamalı, aynı zamanda (ASP.NET'i bilmemelerine rağmen) düzen konusunda uzman olan kişilerin görünümlerde çalışmasını sağlayarak üretiminizi kolaylaştırmanıza izin vermelidir. daha sonra bir geliştirici olarak adım atabilir ve görünümü gerçekten dinamik hale getirebilirsiniz. Bu yalnızca görünüm sözdizimi HTML'ye çok benziyorsa yapılabilir, böylece düzen halkları DreamWeaver'ı veya geçerli popüler düzen aracı ne olursa olsun kullanabilir. Aynı anda düzinelerce site inşa ediyor olabilirsiniz ve üretim verimliliği için bu şekilde ölçeklendirmeniz gerekebilir. "Dil" görüşünün nasıl çalıştığına bir örnek vereyim:

<span mvc:if="ViewData.Model.ShowPrevious" style="float: left;">
    <a mvc:inner="ViewData.Model.PreviousPost.Subject" href="view/{ViewData.Model.PreviousPost.Id}">sample previous subject</a>
</span> 
<span mvc:if="ViewData.Model.ShowNext" style="float: left;">
    <a mvc:inner="ViewData.Model.NextPost.Subject" href="view/{ViewData.Model.NextPost.Id}">sample next subject</a>
</span> 
<div mvc:if="ViewData.Model.ShowNextOrPrevious" style="clear: both;" />

Bunun birkaç avantajı vardır:

• daha iyi görünüyor
• daha özlü
• HTML ve <%%> etiketleri arasında korkak bağlam geçişi yok
• kendini açıklayan anahtar kelimeleri anlaması kolay (programcı olmayan biri bile bunu yapabilir - paralelleştirme için iyi)
• mümkün olduğunca mantık denetleyiciye (veya modele) geri taşındı
• HTML oluşturmaz - yine, Html ile uğraşmak zorunda kalmadan birisinin içeri girmesini ve bir şeyi nerede şekillendireceğini bilmesini kolaylaştırır. yöntemleri
• kodda, görünümü tarayıcıya düz HTML olarak yüklediğinizde görüntülenen örnek metin bulunur (yine düzen mizanpajlı kişiler için iyidir)

Peki, bu sözdizimi tam olarak ne yapıyor?

mvc: inner = "" - tırnak işaretleri ne olursa olsun değerlendirilir ve etiketin iç HTML'si elde edilen dizeyle değiştirilir. (Örnek metnimiz değiştirildi)

mvc: external = "" - tırnak işaretleri ne olursa olsun değerlendirilir ve etiketin dış HTML'si elde edilen dizeyle değiştirilir. (Yine, örnek metin değiştirilir.)

{} - bu, <% =%> öğesine benzer şekilde niteliklerin içine çıktı eklemek için kullanılır

mvc: if = "" - insde qoutes değerlendirilecek boole ifadesidir. HTML etiketinin kapatıldığı yer HTML etiketinin kapatıldığı yerdir.

MVC: Başka

mcv: elseif = "" - ...

MVC: foreach

Şimdi burada sadece kendim için konuşabiliyorum:

IMO, eğer zor bir şeyseniz (herhangi bir şey) dönüşüm sizin için değildir. WebForms'u seviyorsanız, bunun için ihtiyacınız olanı başarabilirsiniz ve bu da herhangi birinin amacıdır.

Webforms, geliştiriciden HTML soyutlamak için iyi bir iş çıkarır . Hedefiniz buysa, Web Formlarına sadık kalın. Masaüstü geliştirmeyi bugünkü haline getiren harika "tıklayın ve sürükleyin" işlevine sahipsiniz. Farklı işlevler getirebilecek birçok kontrol (artı bir dizi üçüncü taraf kontrolü) vardır. Bir DataSource ile doğrudan ilişkili olan bir "ızgarayı" veritabanınızdan sürükleyebilirsiniz; yerleşik satır içi düzenleme, sayfalama vb.Ile birlikte gelir.

Şu an itibariyle, ASP.NET MVC üçüncü taraf denetimleri açısından çok sınırlıdır. Yine, sizin için çok fazla işlevin bağlı olduğu Hızlı Uygulama Geliştirme'yi seviyorsanız, dönüştürülmeye çalışmamalısınız.

Tüm bu dedi, ASP.NET burada parlıyor: - TDD. Nuff, kodun test edilemez olduğunu söyledi.

• Endişelerin ayrılması. MVC modelinin omurgası budur. Bunu Web Formlarında yapabileceğinizin tamamen farkındayım. Ancak, dayatılan yapıyı seviyorum. Web Formlarında tasarımı ve mantığı karıştırmak çok kolaydı. ASP.NET MVC, bir ekibin farklı üyelerinin uygulamanın farklı bölümlerinde çalışmasını kolaylaştırır.

• Başka bir yerden geliyor: Geçmişim CakePHP ve Ruby on Rails. Yani, önyargımın nerede yattığı açık. Bu sadece neyle rahat olduğunuzla ilgilidir.

• Öğrenme Eğrisi: Son noktayı genişletmek; Farklı öğelerin işlevselliğini değiştirmek için "şablonlama" fikrinden nefret ettim. Tasarımın çoğunun dosyanın arkasındaki kodda gerçekleştirildiği gerçeğini beğenmedim. HTML ve CSS'yi zaten yakından tanıdığım bir şey daha öğrenmekti. Sayfadaki bir "öğede" bir şey yapmak istersem, bir "div" ya da "açıklık" yapıştırabilirim, üzerine bir kimlik atarım ve kapatırım. Web Formlarında bunun nasıl yapılacağını araştırmam gerekiyordu.

• Mevcut Web Durumu "Tasarım": jQuery gibi Javascript kütüphaneleri giderek yaygınlaşmaktadır. Web Formlarının kimliklerinizi yönetme biçimi uygulamayı (Visual Studio dışında) zorlaştırır.

• Daha Fazla Ayırma (Tasarım): Tasarımın çoğu kontrolünüze bağlandığından, bir dış tasarımcı (Web Formları olmadan) bilgisinin bir Web Formları projesinde çalışması çok zor olacaktır. Web Formları her şeyin sonu ve hepsi olacak şekilde oluşturulmuştur.

Yine, bu nedenlerin çoğu Web Formlarına aşina olmadığımdan kaynaklanmaktadır. Bir Web Formları projesi (eğer doğru tasarlanmışsa) ASP.NET MVC'nin avantajlarından en çoğuna sahip olabilir. Ama bu uyarı: "Doğru tasarlanmışsa". Ve bu sadece Web Formlarında nasıl yapılacağını bilmediğim bir şey.

Web Formlarında yıldız işi yapıyorsanız, verimlisiniz ve sizin için çalışıyor, kalmanız gereken yer burası.

Temel olarak, artılarını ve eksilerini içeren bir liste ile her ikisini de hızlıca gözden geçirin (tarafsız bir kaynak [iyi şanslar bulmaya çalışın), hangisinin hedeflerinize uyduğunu değerlendirin ve buna göre seçim yapın.

Sonuç olarak, hedeflerinize ulaşmak için en az direnç ve en çok fayda sağlayan yolu seçin. Web Formları çok olgun bir çerçevedir ve yalnızca gelecekte daha iyi hale gelecektir. ASP.NET MVC başka bir alternatiftir (Ruby on Rails ve benim gibi CakePHP geliştiricilerini çekmek için)

Java EE'nin JSP'leri ilk önerildiklerinde böyle görünüyordu - çirkin scriptlet kodu.

Sonra onları daha fazla HTML tag-ish yapmak için etiket kütüphaneleri sundular. Sorun şu ki, herkes bir etiket kitaplığı yazabiliyordu. Bazı sonuçlar felaketti, çünkü insanlar HTML üreten etiket kitaplıklarına çok fazla mantık (ve hatta stil) yerleştirdiler.

Bence en iyi çözüm JSP Standart Etiket Kütüphanesi (JSTL). Bu "standart", HTML tag-ish'dir ve kullanıcıların sayfalara mantık koymasını önlemeye yardımcı olur.

Ek bir fayda, web tasarımcıları ve geliştiriciler arasındaki sınır çizgisini korumasıdır. Gördüğüm iyi yerler estetik anlamda insanlar tarafından kullanılabilirlik için tasarlandı. Sayfaları ve CSS'yi düzenler ve dinamik veri bitlerini ekleyen geliştiricilere iletirler. Bu hediyelerden yoksun bir geliştirici olarak konuşurken, geliştiricilerden çorbadan fındıklara web sayfaları yazmalarını istediğimizde önemli bir şey verdiğimizi düşünüyorum. Flex ve Silverlight aynı sorundan muzdarip olacak, çünkü tasarımcıların JavaScript ve AJAX'ı iyi tanımaları pek mümkün değil.

.NET'in JSTL'ye benzer bir yolu varsa, içine bakmalarını tavsiye ederim.

ASP .NET MVC 3'ten bu yana varsayılan yeni parlak Razor görünüm motoruyla bu örneğin nasıl göründüğünü paylaşacağımı düşündüm .

@{ 
    var prevPost = ViewData.Model.PreviousPost;
    var nextPost = ViewData.Model.NextPost;
}

@if (prevPost != null || nextPost != null) {
    <div>
        @if (prevPost != null) {
            <span style="float: left;">
                @Html.ActionLink("<< " + prevPost.Subject, "view", new { id = prevPost.Id })
            </span>
        }
        @if (nextPost != null) {
            <span style="float: left;">
                @Html.ActionLink(nextPost.Subject + " >>", "view", new { id = nextPost.Id })
            </span>
        }
        <div style="clear: both;" />
    </div>
}

Bununla ilgili bir sorun mu var?
Ayrıca, aslında CSS stillerini satır içi yapmamalısın, değil mi? Ve neden sadece iki yerine üç yerde hükümsüzlüğü kontrol ediyorsunuz? Ekstra divnadiren acıyor. Ben böyle yapardım:

<div>
    @if (prevPost != null) {
        @Html.ActionLink("<< " + prevPost.Subject, "view",
            new { id = prevPost.Id, @class = "prev-link" })
    }
    @if (nextPost != null) {
        @Html.ActionLink(nextPost.Subject + " >>", "view",
            new { id = nextPost.Id, @class = "next-link" })
    }
    <div class="clear" />
</div>

Doğrudan ASP.NET MVC projesiyle konuşamıyorum, ancak genel olarak konuşan MVC çerçeveleri web uygulaması geliştirmeye hükmetmeye geldi çünkü

1. Veritabanı İşlemleri, "İş Mantığı" ve Sunum arasında resmi bir ayrım sunarlar.

2. Geliştiricilerin HTML / CSS / Javascript'lerini birden çok tarayıcıda ve bu tarayıcıların gelecekteki sürümlerinde çalışmasına izin verecek şekilde görünümde yeterli esneklik sunarlar.

Önemli olan bu son parça. Web formları ve benzer teknolojilerle, HTML / CSS / Javascript'inizi sizin için yazmak için satıcınıza güveniyorsunuz. Bu güçlü şeyler, ancak Webforms'un mevcut sürümünün yeni nesil web tarayıcılarıyla çalışacağına dair bir garantiniz yok.

Bu görüşün gücü. Uygulamanızın HTML'si üzerinde tam kontrole sahip olursunuz. Dezavantajı, mantığı görünümlerinizde minimumda tutacak kadar disiplinli olmanız ve şablon kodunu olabildiğince basit tutmanızdır.

Yani, bu değiş tokuş. Web formları sizin için çalışıyorsa ve MVC çalışmıyorsa, Web formlarını kullanmaya devam edin

Onunla ilgili hayal kırıklığımın çoğu, şeylerin nasıl "düzgün" yapılacağını bilmek değildir. Bir önizleme olarak piyasaya sürüldüğünden beri, hepimiz şeylere bakmak için biraz zamanımız vardı, ancak biraz değişiyorlar. İlk başta gerçekten hayal kırıklığına uğradım, ancak çerçeve oldukça karmaşık UI'ler (okuma: Javascript) oluşturmamı sağlayacak kadar uygulanabilir görünüyor. Bunu daha önce yaptığım gibi Webforms ile yapabileceğinizi anlıyorum, ancak popodaki her şeyin doğru şekilde işlenmesini sağlamaya çalışan büyük bir acıydı. Çoğu zaman, kesin çıktıyı kontrol etmek için bir tekrarlayıcı kullanarak sona erer ve yukarıda da sahip olduğunuz spagetti karışıklığıyla sonuçlanır.

Aynı karmaşaya sahip olmamak için, görünüme aktarmak için etki alanı, hizmet katmanları ve bir dto'ya sahip olmanın bir kombinasyonunu kullanıyorum. Bunu kıvılcım, bir görüntü motoru ile bir araya getirin ve gerçekten güzelleşir. Kurulumu biraz zaman alır, ancak bir kez devam ederseniz, görsel olarak uygulamalarımın karmaşıklığında büyük bir adım gördüm, ancak kod akıllıca yapmak çok basit.

Muhtemelen böyle yapmazdım ama işte senin örnek:

<if condition="myDtp.ShowPager">
  <div>
    <first />
    <last />
    <div style="clear: both;" />
  </div>
</if>

Bu oldukça korunabilir, test edilebilir ve benim kod çorba nefis tadı.

Paket servisi olan restoran temiz kod gerçekten mümkün, ama biz bir şeyler yapmak yolundan büyük bir eşek kayması olduğunu. Yine de herkesin bunu düşündüğünü sanmıyorum. Hala çözdüğümü biliyorum ...

Steve Sanderson'un Apress'ten yakın zamanda yayınlanan 'Pro ASP.NET MVC' [1] [2] adlı kitabı başka bir alternatif öneriyor - özel bir HtmlHelper uzantısı oluşturuyor. Onun örneği (Bölüm 4, sayfa 110), sayfalanmış liste örneğini kullanır, ancak durumunuza kolayca uyarlanabilir.

public static string PostNavigator(this HtmlHelper html, Post previous, Post next, Func<int, string> pageUrl)
{
    StringBuilder result = new StringBuilder();

    if (previous != null || next != null)
    {
        result.Append("<div>");

        if (previous != null)
        {
            result.Append(@"<span class=""left"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(previous.Id));
            link.InnerHtml = String.Format("<< {0}", html.Encode(previous.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        if (next != null)
        {
            if (previous != null)
            {
                result.Append(" ");
            }

            result.Append(@"<span class=""right"">");
            TagBuilder link = new TagBuilder("a");
            link.MergeAttribute("href", pageUrl(next.Id));
            link.InnerHtml = String.Format("{0} >>", html.Encode(next.Subject));
            result.Append(link.ToString());
            result.Append("</span>");
        }

        result.Append("</div>");
    }

    return result.ToString();
}

Bu kodu, görünümünüzde şöyle bir kodla adlandırabilirsiniz:

<%= Html.PostNavigator(ViewData.Model.PreviousPost, ViewData.Model.NextPost, id => Url.Action("View", new { postId = id })) %>

[1] http://blog.codeville.net/2009/04/29/now-published-pro-aspnet-mvc-framework-apress/

[2] http://books.google.com/books?id=Xb3a1xTSfZgC

Phil Haack'ten bir yazı görmeyi umuyordum, ama burada değildi, bu yüzden sadece http://blog.wekeroad.com/blog/i-spose-ill-just-say-it-you-should -learn-mvc / yorumlar bölümünde

Kaçırıldı - 23 Nisan 2009 - Rob, sen bir isyansın! :) İnsanlar MVC spagetti kodu yazıp sonra "bak! Spagetti!" Hey, Web Formlarına da spagetti kodu yazabilirim! Raylar, PHP, Java, Javascript yazabilirim, ancak Lisp yazamıyorum. Ama sadece Lisp'e henüz bir şey yazamadığım için. Ve spagetti kodu yazdığımda, makarnayı görmek için beklediğim tabaklara bakmıyorum. İnsanların klasik ASP ile karşılaştırırken sıklıkla vurguladıkları nokta, klasik ASP insanlarıyla endişeleri karıştırma eğilimindedir. Sayfalarda, kullanıcı girişi işlemenin model kodu ve iş mantığı bir arada karıştırılmış görünüm mantığı bulunur. Spagetti buydu! Endişeleri karıştırmak büyük bir karmaşa içinde. ASP.NET MVC ile, kalıbı takip ederseniz, bunu yapma olasılığı düşüktür. Evet, yine de görünümünüzde biraz kod olabilir, ancak umarım hepsi görünüm kodudur. Kalıp, kullanıcı etkileşim kodunuzu oraya koymamanızı önerir. Denetleyiciye koyun. Model kodunuzu bir model sınıfına yerleştirin. Orada. Spagetti yok. Şimdi O-Toro Sushi. :)

Ben de; ASP.NET MVC yerine Silverlight üzerinde zaman harcayacağım. MVC 1.0'ı denedim ve birkaç gün önce en son 2.0 Beta 1 sürümüne baktım.

ASP.NET MVC nasıl webform daha iyi olduğunu hissedemiyorum. MVC'nin satış noktası:

1. Ünite testi)
   
2. Tasarımı (görünümü) ve mantığı (kontrolör + model) ayırın
   
3. Görünüm durumu yok ve daha iyi öğe kimliği yönetimi
   
4. RESTful URL ve daha fazlası ...

Ancak, arka plan kodunu kullanarak webform.Tema, Kaplama ve Kaynak tasarımı ve mantığı ayırmak için zaten mükemmel.

Viewstate: ASP.NET 4.0'da istemci kimliği yönetimi geliyor. Sadece birim testleri ile ilgili endişeliyim, ancak birim testleri beni web formundan ASP.NET MVC'ye çevirmek için yeterli bir neden değil.

Belki söyleyebilirim: ASP.NET MVC kötü değil, ama webform zaten yeterli.

Önizleme 3 çıktığından beri MVC kullanıyorum ve hala büyüyen ağrıları varken, takım geliştirme alanında biraz yardımcı oluyor. Üç kişinin tek bir web formu sayfasında çalışmasını sağlayın, ardından başınızı duvara vurma kavramını anlayacaksınız. Görünüm sayfasındaki tasarım öğelerini anlayan bir geliştiriciyle ve her şeyi denetleyicide bir araya getirirken modelin çalışmasında yerleşik Linq tanrımızla çalışabilirim. Endişelerin ayrılmasının bu kadar kolay olduğu bir alanda hiçbir zaman gelişemedim.

ASP.Net MVC - StackOverflow en büyük satış noktası MVC yığını üzerinde çalışır.

Olduğu söyleniyor ... kodunuz normalde görünüm sayfası ile yaptığımdan çok daha güzel. Ayrıca, birlikte çalıştığım adamlardan biri HTML yardımcısını bir etiket kitaplığına sarmak için çalışıyor. <% = Html.RandomFunctionHere ()%> yerine şu şekilde çalışır:

<ss: rasgele işlev />

Umarım MVC ekibi bir noktada ona ulaşır çünkü eminim daha iyi bir iş çıkarırlardı.

Görüntülemeniz gereken tüm veriler için tüm mantığı sarmak için bir Cephe Deseni kullanın ve daha sonra görünümünüzde jenerik olarak kullanın ve ... artık spagetti kodu yok. http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

Daha fazla yardıma ihtiyacınız varsa cgardner2020@gmail.com

ASP.NET MVC uygulaması korkunç. Ürün düz berbat. Birkaç demo gördüm ve MSFT'den utanıyorum ... Eminim ki yazanlar benden daha akıllıdır, ama sanki Model-View-Controller'ın ne olduğunu bilmiyorlarmış gibi .

MVC'yi uygulamaya çalıştığını bildiğim tek insanlar MSFT'den yeni şeyler denemek isteyen insanlar. Gördüğüm demolarda sunum yapan kişinin özür dileyen bir tonu vardı ...

MSFT'nin büyük bir hayranıyım, ancak MVC uygulamalarını rahatsız etmek için hiçbir neden görmediğimi söylemeliyim. Web Formları kullanın veya web geliştirme için jquery kullanın, bu iğrençliği seçmeyin.

DÜZENLE:

Model-View-Controller mimari tasarım modelinin amacı, alan adınızı sunumdan iş kurallarından ayırmaktır. Deseni, uyguladığım her Web Forms projesinde başarıyla kullandım. ASP.NET MVC ürünü, gerçek mimari tasarım modeline iyi uyum sağlamaz.