Apakah ada orang di samping saya yang TIDAK mendapatkan ASP.NET MVC? [Tutup]

Saya sudah mengutak-atik ASP.NET MVC sejak CTP, dan saya suka banyak hal yang mereka lakukan, tetapi ada hal-hal yang tidak saya dapatkan.

Sebagai contoh, saya mengunduh beta1, dan saya mengumpulkan sedikit situs pribadi / resume / blog dengannya. Berikut ini cuplikan dari tampilan ViewSinglePost:

 <%
        // 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> <%
        }
    %>

Menjijikkan! (Perhatikan juga bahwa HTML ada HTML placeholder sementara, saya akan membuat desain yang sebenarnya setelah fungsionalitas berfungsi) .

Apakah saya melakukan sesuatu yang salah? Karena saya menghabiskan banyak hari-hari kelam dalam ASP klasik, dan sup tag ini sangat mengingatkan saya pada itu.

Semua orang mengajarkan bagaimana Anda bisa melakukan HTML bersih. Tebak apa? 1% dari semua orang melihat HTML yang dihasilkan. Bagi saya, saya tidak peduli jika Webforms mengacaukan indentasi saya dalam HTML yang diberikan, asalkan saya memiliki kode yang mudah dipelihara ... Ini bukan!

Jadi, konversi saya, seorang pria webform yang sangat sulit, mengapa saya harus menyerahkan halaman ASPX saya yang bagus untuk ini?

Sunting: Menebalkan baris "temp Html / css" sehingga orang akan stfu tentang hal itu.

Dibandingkan dengan Formulir Web, MVC secara bersamaan merupakan pendekatan tingkat rendah untuk pembuatan HTML dengan kontrol yang lebih besar terhadap output halaman dan pendekatan tingkat tinggi yang lebih digerakkan oleh arsitektur. Izinkan saya menangkap Formulir Web dan MVC dan tunjukkan mengapa saya pikir perbandingannya mendukung Formulir Web dalam banyak situasi - selama Anda tidak jatuh ke dalam beberapa perangkap Formulir Web klasik.

Formulir Web

Dalam model Formulir Web, halaman Anda berhubungan langsung dengan permintaan halaman dari browser. Dengan demikian, jika Anda mengarahkan pengguna ke daftar Buku, Anda mungkin akan memiliki halaman di suatu tempat yang disebut "Booklist.aspx" di mana Anda akan mengarahkannya. Di halaman itu, Anda harus memberikan semua yang diperlukan untuk menunjukkan daftar itu. Ini termasuk kode untuk menarik data, menerapkan logika bisnis apa pun, dan menampilkan hasilnya. Jika ada logika arsitektur atau perutean yang mempengaruhi halaman, Anda juga harus membuat kode logika arsitektur di halaman tersebut. Pengembangan Formulir Web yang baik biasanya melibatkan pengembangan satu set kelas pendukung di DLL yang terpisah (unit-testable). Kelas-kelas ini akan menangani logika bisnis, akses data dan keputusan arsitektur / routing.

MVC

MVC mengambil pandangan yang lebih "arsitektural" dari pengembangan aplikasi web: menawarkan perancah standar untuk membangun. Ini juga menyediakan alat untuk secara otomatis menghasilkan kelas model, tampilan dan pengontrol dalam arsitektur yang sudah ada. Misalnya, di Ruby on Rails (hanya "Rails" dari sini dan seterusnya) dan ASP.NET MVC Anda akan selalu memulai dengan struktur direktori yang mencerminkan keseluruhan model arsitektur aplikasi web mereka. Untuk menambahkan tampilan, model, dan pengontrol, Anda akan menggunakan perintah seperti Rails "Rails script / generate scaffold {modelname}" (ASP.NET MVC menawarkan perintah serupa di IDE). Di kelas pengontrol yang dihasilkan, akan ada metode ("Tindakan") untuk Indeks (tampilkan daftar), Tampilkan, Baru dan Edit dan Hancurkan (setidaknya di Rails, MVC serupa). Secara default, ini "

Tata letak direktori dan file penting dalam MVC. Misalnya, dalam ASP.NET MVC, metode Indeks untuk objek "Buku" kemungkinan hanya memiliki satu baris: "Return View ();" Melalui keajaiban MVC, ini akan mengirim model Buku ke halaman "/View/Books/Index.aspx" di mana Anda akan menemukan kode untuk menampilkan Buku. Pendekatan Rails serupa meskipun logikanya sedikit lebih eksplisit dan kurang "ajaib". Sebuah Lihat halaman dalam sebuah aplikasi MVC biasanya lebih sederhana daripada sebuah halaman Web Forms karena mereka tidak perlu khawatir karena banyak tentang routing yang, logika bisnis atau penanganan data.

Perbandingan

Keuntungan MVC berkisar pada pemisahan masalah yang bersih dan model yang lebih bersih, HTML / CSS / AJAX / Javascript-sentris untuk menghasilkan output Anda. Ini meningkatkan kemampuan uji, menyediakan desain yang lebih standar dan membuka pintu ke jenis situs web yang lebih "Web 2.0".

Namun, ada beberapa kelemahan yang signifikan juga.

Pertama, meskipun mudah untuk membuat situs demo berjalan, model arsitektur keseluruhan memiliki kurva belajar yang signifikan. Ketika mereka mengatakan "Convention Over Configuration" kedengarannya bagus - sampai Anda menyadari bahwa Anda memiliki konvensi yang layak untuk dipelajari. Selain itu, sering sedikit menjengkelkan untuk mencari tahu apa yang terjadi karena Anda sedang mengandalkan magic daripada panggilan eksplisit. Misalnya, bahwa "Return View ();" telepon di atas? Panggilan yang sama persis dapat ditemukan di Tindakan lain tetapi mereka pergi ke tempat yang berbeda. Jika Anda memahami konvensi MVCmaka Anda tahu mengapa ini dilakukan. Namun, itu tentu saja tidak memenuhi syarat sebagai contoh penamaan yang baik atau kode yang mudah dimengerti dan jauh lebih sulit bagi pengembang baru untuk mengambil dari Formulir Web (ini bukan hanya pendapat: Saya memiliki pekerja magang musim panas mempelajari Formulir Web tahun lalu dan MVC tahun ini dan perbedaan produktivitas diucapkan - mendukung Formulir Web). BTW, Rails sedikit lebih baik dalam hal ini meskipun Ruby on Rails fitur metode dinamis yang mengambil beberapa membiasakan diri juga.

Kedua, MVC secara implisit mengasumsikan bahwa Anda sedang membangun situs web gaya CRUD klasik. Keputusan arsitektur dan terutama pembuat kode dibuat untuk mendukung jenis aplikasi web ini. Jika Anda sedang membangun aplikasi CRUD dan ingin mengadopsi arsitektur yang terbukti (atau hanya tidak suka desain arsitektur), maka Anda mungkin harus mempertimbangkan MVC. Namun, jika Anda akan melakukan lebih dari CRUD dan / atau Anda cukup kompeten dengan arsitektur maka MVC mungkin terasa seperti straightjacket sampai Anda benar-benar menguasai model perutean yang mendasarinya (yang jauh lebih kompleks daripada hanya perutean dalam aplikasi WebForms). Bahkan kemudian, saya merasa seperti saya selalu melawan model dan khawatir tentang hasil yang tidak terduga.

Ketiga, jika Anda tidak peduli dengan Linq (baik karena Anda takut Linq-to-SQL akan hilang atau karena Anda menemukan Linq-to-Entities secara berlebihan diproduksi di bawah dan di bawah daya) maka Anda juga tidak ingin untuk berjalan di jalur ini karena alat perancah ASP.NET MVC dibangun di sekitar Linq (ini adalah pembunuh bagi saya). Model data Rails juga cukup canggung dibandingkan dengan apa yang dapat Anda capai jika Anda berpengalaman dalam SQL (dan terutama jika Anda berpengalaman dalam TSQL dan prosedur tersimpan!).

Keempat, pendukung MVC sering menunjukkan bahwa pandangan MVC lebih dekat dengan model HTML / CSS / AJAX web. Misalnya, "HTML Helpers" - panggilan kode kecil di halaman Anda yang bertukar konten dan menempatkannya ke dalam kontrol HTML - jauh lebih mudah untuk diintegrasikan dengan Javascript daripada kontrol Formulir Web. Namun, ASP.NET 4.0 memperkenalkan kemampuan untuk memberi nama kontrol Anda dan karenanya sangat menghilangkan keuntungan ini.

Kelima, puritan MVC sering mencemooh Viewstate. Dalam beberapa kasus, mereka berhak melakukannya. Namun, Viewstate juga bisa menjadi alat yang hebat dan anugerah bagi produktivitas. Sebagai perbandingan, menangani kondisi tampilan jauh lebih mudah daripada mencoba mengintegrasikan kontrol web pihak ketiga dalam aplikasi MVC. Sementara integrasi kontrol mungkin lebih mudah untuk MVC, semua upaya saat ini yang saya lihat menderita dari kebutuhan untuk membangun (agak grody) kode untuk menghubungkan kontrol ini kembali ke kelas Controller view (yaitu - untuk bekerja di sekitar model MVC ).

Kesimpulan

Saya suka pengembangan MVC dalam banyak hal (walaupun saya lebih suka Rails daripada ASP.NET MVC jika perlu waktu lama). Saya juga berpikir bahwa penting bagi kita untuk tidak terjebak dalam pemikiran bahwa ASP.NET MVC adalah "anti-pola" dari Formulir Web ASP.NET. Mereka berbeda tetapi tidak sepenuhnya asing dan tentu saja ada ruang untuk keduanya.

Namun, saya lebih suka pengembangan Formulir Web karena, untuk sebagian besar tugas , itu lebih mudah untuk menyelesaikan sesuatu (pengecualian menjadi pembuatan satu set formulir CRUD). MVC juga tampaknya menderita, sampai batas tertentu, dari kelebihan teori. Memang, lihat banyak pertanyaan yang diajukan di sini pada SO oleh orang-orang yang tahu ASP.NET berorientasi halaman tetapi yang mencoba MVC. Tanpa pengecualian, ada banyak kertakan gigi karena pengembang menemukan bahwa mereka tidak dapat melakukan tugas-tugas dasar tanpa melewati rintangan atau bertahan dalam kurva belajar yang besar. Inilah yang membuat Formulir Web lebih unggul dari MVC dalam buku saya: MVC membuat Anda membayar harga dunia nyata untuk mendapatkan sedikit lebih banyak testability atau, lebih buruk lagi, hanya terlihat keren karena Anda menggunakanteknologi terbaru.

Pembaruan: Saya banyak dikritik di bagian komentar - beberapa di antaranya cukup adil. Jadi, saya telah menghabiskan beberapa bulan mempelajari Rails dan ASP.NET MVC hanya untuk memastikan saya tidak benar-benar kehilangan hal besar berikutnya! Tentu saja, ini juga membantu memastikan bahwa saya memberikan respons yang seimbang dan sesuai untuk pertanyaan itu. Anda harus tahu bahwa respons di atas adalah penulisan ulang utama dari jawaban awal saya jika komentarnya tampaknya tidak selaras.

Ketika saya melihat lebih dekat ke MVC saya berpikir, untuk sementara, bahwa saya akan berakhir dengan mea culpa utama. Pada akhirnya saya menyimpulkan bahwa, sementara saya pikir kita perlu menghabiskan lebih banyak energi pada arsitektur Formulir Web dan testability, MVC benar-benar tidak menjawab panggilan untuk saya. Jadi, "terima kasih" yang tulus kepada orang-orang yang memberikan kritik cerdas atas jawaban awal saya.

Mengenai mereka yang melihat ini sebagai pertarungan agama dan yang tanpa henti merekayasa banjir downvote, saya tidak mengerti mengapa Anda repot-repot (20+ suara turun dalam hitungan detik satu sama lain pada beberapa kesempatan tentu tidak normal). Jika Anda membaca jawaban ini dan bertanya-tanya apakah ada sesuatu yang benar-benar "salah" tentang jawaban saya mengingat bahwa skornya jauh lebih rendah daripada beberapa jawaban lainnya, yakinlah bahwa itu mengatakan lebih banyak tentang beberapa orang yang tidak setuju daripada pengertian umum tentang komunitas (secara keseluruhan, yang ini telah terunggah lebih dari 100 kali).

Faktanya adalah bahwa banyak pengembang tidak peduli dengan MVC dan, memang, ini bukan pandangan minoritas (bahkan dalam MS seperti yang ditunjukkan oleh blog).

MVC memberi Anda lebih banyak kontrol atas output Anda, dan dengan kontrol itu datang risiko yang lebih besar untuk menulis HTML yang dirancang dengan buruk, sup tag, dll ...

Tetapi pada saat yang sama, Anda memiliki beberapa opsi baru yang sebelumnya tidak Anda miliki ...

1. Lebih banyak kontrol atas halaman dan elemen-elemen di dalam halaman
2. Lebih sedikit "sampah" di output Anda, seperti kondisi tampilan atau terlalu lama ID pada elemen (jangan salah paham, saya suka kondisi tampilan)
3. Kemampuan yang lebih baik untuk melakukan pemrograman sisi klien dengan Javascript (Aplikasi Web 2.0?)
4. Bukan hanya MVC, tapi JsonResult apik ...

Nah, itu bukan untuk mengatakan bahwa Anda tidak dapat melakukan hal-hal ini dengan WebForms, tetapi MVC membuatnya lebih mudah.

Saya masih menggunakan WebForms ketika saya harus membuat aplikasi web dengan cepat karena saya dapat memanfaatkan kontrol server, dll. WebForms menyembunyikan semua detail tag input dan mengirimkan tombol.

Baik WebForms dan MVC mampu menghasilkan sampah absolut jika Anda ceroboh. Seperti biasa, perencanaan yang cermat dan desain yang dipikirkan dengan matang akan menghasilkan aplikasi yang berkualitas, terlepas dari apakah itu MVC atau WebForms.

[Memperbarui]

Jika itu adalah penghiburan juga, MVC hanyalah teknologi baru yang terus berkembang dari Microsoft. Ada banyak posting bahwa WebForms tidak hanya akan tetap, tetapi terus dikembangkan untuk ...

http://haacked.com

http://www.misfitgeek.com

http://rachelappel.com

... dan seterusnya...

Bagi mereka yang khawatir tentang mengambil rute MVC, saya sarankan memberikan "orang-orang" umpan balik Anda. Mereka tampaknya mendengarkan sejauh ini!

Sebagian besar keberatan terhadap ASP.NET MVC tampaknya berpusat di sekitar pandangan, yang merupakan salah satu bit paling "opsional" dan modular dalam arsitektur. NVelocity , NHaml , Spark , XSLT, dan mesin tampilan lainnya dapat dengan mudah diganti (dan semakin mudah dengan setiap rilis). Banyak dari mereka memiliki sintaks yang JAUH lebih ringkas untuk melakukan logika presentasi dan pemformatan, sambil tetap memberikan kontrol penuh atas HTML yang dipancarkan.

Di luar itu, hampir setiap kritik tampaknya bermuara pada <%%> penandaan dalam tampilan default dan seberapa "jeleknya" itu. Pendapat itu sering berakar pada yang digunakan untuk pendekatan WebForms, yang hanya memindahkan sebagian besar keburukan ASP klasik ke dalam file di belakang kode.

Bahkan tanpa melakukan kode-balik "salah", Anda memiliki hal-hal seperti OnItemDataBound di Repeaters, yang sama buruknya secara estetika, jika hanya dengan cara yang berbeda, daripada "tag soup". Sebuah foreach loop bisa lebih mudah dibaca, bahkan dengan variabel embedding dalam output loop itu, terutama jika Anda datang ke MVC dari teknologi non-ASP.NET lainnya. Dibutuhkan jauh lebih sedikit Google-fu untuk memahami loop foreach daripada mengetahui bahwa cara untuk memodifikasi satu bidang di pengulang Anda adalah dengan mengacaukan OnItemDataBound (dan sarang tikus untuk memeriksa apakah elemen yang tepat untuk diubah.

Masalah terbesar dengan "spaghetti" yang digerakkan oleh tag ASP adalah tentang mendorong hal-hal seperti koneksi database tepat di antara HTML.

Yang kebetulan melakukannya dengan menggunakan <%%> hanyalah korelasi dengan sifat spageti ASP klasik, bukan sebab-akibat. Jika Anda menyimpan logika tampilan ke HTML / CSS / Javascript dan logika minimal yang diperlukan untuk melakukan presentasi , sisanya adalah sintaksis.

Ketika membandingkan sedikit fungsionalitas yang diberikan dengan WebForms, pastikan untuk menyertakan semua C # yang dihasilkan oleh desainer, dan kode-balik C # bersama dengan kode .aspx untuk memastikan bahwa solusi MVC benar-benar tidak, pada kenyataannya, jauh lebih sederhana .

Ketika dikombinasikan dengan penggunaan tampilan parsial secara bijaksana untuk bit logika presentasi yang berulang, itu bisa sangat bagus dan elegan.

Secara pribadi, saya berharap sebagian besar konten tutorial awal lebih terfokus pada akhir ini daripada hampir secara eksklusif pada tes-driven, inversi kontrol, dll. Sementara itu hal-hal lain yang menjadi tujuan para ahli, orang-orang di parit lebih cenderung untuk menolak "sup tag".

Apapun, ini adalah platform yang masih dalam versi beta. Meskipun demikian, itu mendapatkan WAY lebih banyak penyebaran dan pengembang non-Microsoft membangun hal-hal yang sebenarnya dengan itu daripada kebanyakan teknologi Microsoft-beta. Dengan demikian, buzz cenderung membuatnya tampak seperti lebih jauh daripada infrastruktur di sekitarnya (dokumentasi, pola panduan, dll). Menjadi benar-benar dapat digunakan pada titik ini hanya memperkuat efek itu.

<% 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>
<% } %>

Anda dapat membuat posting lain yang menanyakan cara melakukan ini tanpa menyertakan embeded CSS.

CATATAN: ViewData.Model menjadi Model dalam rilis berikutnya.

Dan dengan bantuan kontrol pengguna ini akan menjadi

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

di mana PagerData diinisialisasi melalui konstruktor anonim di penangan tindakan.

sunting: Saya ingin tahu seperti apa implementasi WebForm Anda nantinya untuk masalah ini.

Saya tidak yakin pada titik mana orang berhenti memperhatikan kode mereka.

HTML adalah tampilan pekerjaan Anda yang paling umum, ada BANYAK pengembang di luar sana yang menggunakan notepad, notepad ++, dan editor teks biasa lainnya untuk membangun banyak situs web.

MVC adalah tentang mendapatkan kontrol kembali dari formulir web, bekerja di lingkungan tanpa kewarganegaraan, dan menerapkan pola desain Pengendali Model View tanpa semua pekerjaan ekstra yang biasanya terjadi dalam penerapan pola ini.

Jika Anda ingin mengontrol, membersihkan kode, dan menggunakan pola desain MVC, ini untuk Anda, jika Anda tidak suka bekerja dengan markup, tidak peduli tentang bagaimana cacat markup Anda, kemudian gunakan Formulir Web ASP.Net.

Jika Anda tidak menyukai keduanya, Anda pasti akan melakukan hampir semua pekerjaan di markup.

EDIT I Harus juga menyatakan bahwa Formulir Web dan MVC memiliki tempat mereka, saya sama sekali tidak menyatakan bahwa satu lebih baik dari yang lain, hanya bahwa setiap MVC memiliki kekuatan untuk mendapatkan kembali kendali atas markup.

Saya pikir Anda kehilangan beberapa hal. Pertama, tidak perlu untuk Response.Write, Anda dapat menggunakan<%= %> tag. Kedua, Anda dapat menulis ekstensi HtmlHelper Anda sendiri untuk melakukan tindakan umum. Ketiga, sedikit memformat sangat membantu. Keempat, semua ini mungkin akan terjebak dalam kontrol pengguna untuk dibagikan antara beberapa pandangan yang berbeda dan dengan demikian keseluruhan mark up pada tampilan utama lebih bersih.

Saya akan memberi tahu Anda bahwa mark up masih tidak serapi yang diinginkan, tetapi dapat dibersihkan secara signifikan melalui penggunaan beberapa variabel sementara.

Nah, itu tidak terlalu buruk dan akan lebih baik jika saya tidak harus memformatnya untuk SO.

 <%
    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>

  <% } %>

Masalah besar dengan MVC adalah bahwa itu adalah kerangka kerja konseptual yang telah ada sejak lama, dan telah membuktikan dirinya sebagai cara yang produktif dan kuat untuk membangun aplikasi web dan aplikasi workstation yang berskala horizontal dan vertikal. Ini langsung kembali ke Alto dan Smalltalk. Microsoft terlambat ke pesta. Apa yang kita miliki sekarang dengan ASP.NET MVC benar-benar primitif, karena ada begitu banyak yang harus dilakukan; tapi sial, mereka menuangkan rilis baru dengan cepat dan berapi-api.

Apa masalahnya dengan Ruby on Rails? Rails adalah MVC. Pengembang telah melakukan konversi karena, dari mulut ke mulut, ini menjadi cara bagi programmer untuk menjadi produktif.

Ini masalah besar; MVC dan dukungan implisit jQuery adalah titik kritis bagi Microsoft untuk menerima bahwa platform-neutral sangat penting. Dan yang netral tentang hal itu, adalah bahwa tidak seperti Formulir Web, Microsoft tidak dapat mengunci Anda secara konseptual. Anda dapat mengambil semua kode C # dan menerapkannya kembali dalam bahasa lain sepenuhnya (katakanlah PHP atau java - sebut saja) karena itu adalah konsep MVC yang portabel, bukan kode itu sendiri. (Dan pikirkan betapa besarnya Anda dapat mengambil desain Anda dan mengimplementasikannya sebagai aplikasi workstation dengan sedikit perubahan kode, dan tanpa perubahan desain. Cobalah dengan Formulir Web.)

Microsoft telah memutuskan bahwa Formulir Web tidak akan menjadi VB6 berikutnya.

Silakan lihat posting Rob Conery I Spose I'll Just Say It: You Should Learn MVC

Dua keuntungan utama kerangka ASP.NET MVC dibandingkan formulir web adalah:

1. Testabilitas - UI dan acara dalam formulir web nyaris tidak mungkin untuk diuji. Dengan ASP.NET MVC, aksi pengontrol unit testing dan pandangan yang mereka buat mudah. Ini datang dengan biaya dalam biaya pengembangan di muka, tetapi penelitian telah menunjukkan bahwa ini terbayar dalam jangka panjang ketika tiba saatnya untuk refactor dan memelihara aplikasi.
2. Kontrol yang lebih baik atas HTML yang diberikan - Anda menyatakan bahwa Anda tidak peduli dengan HTML yang diberikan karena tidak ada yang melihatnya. Itu keluhan yang valid jika itu adalah satu-satunya alasan untuk memformat HTML dengan benar. Ada banyak alasan untuk menginginkan HTML yang diformat dengan baik termasuk: SEO, kemampuan untuk menggunakan pemilih pemilih lebih sering (dalam css dan javascript), jejak kaki halaman yang lebih kecil karena kurangnya kondisi tampilan dan id yang sangat panjang (ctl00_etcetcetc).

Sekarang, alasan-alasan ini tidak benar-benar membuat ASP.NET MVC lebih baik atau lebih buruk daripada formulir web dalam cara hitam-putih. ASP.NET MVC memiliki kekuatan dan kelemahannya, seperti halnya formulir web. Namun, sebagian besar keluhan tentang ASP.NET MVC tampaknya berasal dari kurangnya pemahaman tentang cara menggunakannya daripada kelemahan aktual dalam kerangka kerja. Alasan kode Anda tidak terasa benar atau terlihat benar mungkin karena Anda memiliki beberapa tahun pengalaman formulir web di bawah ikat pinggang Anda dan hanya 1-2 bulan pengalaman ASP.NET MVC.

Masalahnya di sini adalah tidak begitu banyak ASP.NET MVC batu atau menyebalkan, itu baru dan ada sedikit kesepakatan tentang bagaimana menggunakannya dengan benar. ASP.NET MVC menawarkan kontrol yang jauh lebih baik atas apa yang terjadi di aplikasi Anda. Itu dapat membuat tugas-tugas tertentu lebih mudah atau lebih sulit tergantung pada bagaimana Anda mendekatinya.

Hei, aku sudah berjuang dengan beralih ke MVC juga. Saya sama sekali bukan penggemar rendering ASP dan MVC klasik yang mengingatkan saya pada banyak hal saat itu. Namun, semakin saya menggunakan MVC, semakin tumbuh di saya. Saya seorang pria webforms (seperti banyak) dan menghabiskan beberapa tahun terakhir membiasakan diri bekerja dengan datagrids, dll. Dengan MVC yang diambil. Kelas HTML Helper adalah jawabannya.

Baru-baru ini saya menghabiskan 2 hari mencoba mencari cara terbaik untuk menambahkan paging ke "kotak" di MVC. Sekarang, dengan webforms saya bisa mencabut ini dalam waktu singkat. Tapi saya akan mengatakan ini ... begitu saya memiliki kelas helper paging dibangun untuk MVC, itu menjadi sangat sederhana untuk diterapkan. Bagi saya, bahkan lebih mudah daripada formulir web.

Yang sedang berkata, saya berpikir bahwa MVC akan jauh lebih ramah pengembang ketika ada satu set Pembantu HTML yang konsisten di luar sana. Saya pikir kita akan mulai melihat satu ton kelas pembantu HTML muncul di web dalam waktu dekat.

Ini lucu karena itulah yang saya katakan ketika pertama kali melihat formulir web.

Saya akui bahwa saya belum mendapatkan asp.net MVC. Saya mencoba menggunakannya dalam proyek sampingan yang saya lakukan tetapi ini berjalan cukup lambat.

Selain tidak bisa melakukan hal-hal yang begitu mudah dilakukan dalam bentuk web, saya perhatikan sup tag. Tampaknya benar-benar mengambil langkah mundur dari perspektif itu. Saya terus berharap bahwa ketika saya belajar itu akan menjadi lebih baik.

Sejauh ini saya perhatikan bahwa alasan utama untuk menggunakan MVC adalah untuk mendapatkan kontrol penuh atas HTML Anda. Saya juga membaca bahwa asp.net MVC dapat melayani lebih banyak halaman lebih cepat dari formulir web dan mungkin terkait dengan ini, ukuran halaman individu lebih kecil dari halaman formulir web rata-rata.

Saya benar-benar tidak peduli bagaimana rupa HTML saya selama itu bekerja di browser utama, tapi saya peduli seberapa cepat halaman saya memuat dan berapa banyak bandwidth yang diambil.

Sementara saya sepenuhnya setuju bahwa itu adalah markup jelek, saya pikir menggunakan sintaksis tampilan jelek untuk menghapus ASP.NET MVC secara keseluruhan tidak adil. Sintaks tampilan paling sedikit mendapat perhatian dari Microsoft, dan saya sepenuhnya mengharapkan sesuatu untuk segera diselesaikan.

Jawaban lain telah membahas manfaat MVC secara keseluruhan, jadi saya akan fokus pada sintaks tampilan:

Dorongan untuk menggunakan Html.ActionLink dan metode lain yang menghasilkan HTML adalah langkah ke arah yang salah. Ini sedikit sekali kontrol server, dan, bagi saya, memecahkan masalah yang tidak ada. Jika kita akan membuat tag dari kode, lalu mengapa repot-repot menggunakan HTML? Kami hanya dapat menggunakan DOM atau model lain dan membangun konten kami di controller. Ok, kedengarannya buruk, bukan? Oh ya, pemisahan kekhawatiran, itu sebabnya kami memiliki pandangan.

Saya pikir arah yang benar adalah membuat sintaks tampilan sebanyak mungkin HTML. Ingat, MVC yang dirancang dengan baik seharusnya tidak hanya memberi Anda pemisahan kode dari konten, itu juga harus membuat Anda merampingkan produksi Anda dengan meminta orang yang ahli dalam tata letak bekerja pada pandangan (meskipun mereka tidak tahu ASP.NET), dan kemudian nanti sebagai pengembang, Anda dapat masuk dan membuat tampilan maket benar-benar dinamis. Ini hanya dapat dilakukan jika jika sintaks tampilan terlihat sangat mirip HTML, sehingga orang-orang tata letak dapat menggunakan DreamWeaver atau apa pun alat tata letak populer saat ini. Anda mungkin membangun puluhan situs sekaligus, dan perlu meningkatkan efisiensi produksi. Biarkan saya memberikan contoh bagaimana saya bisa melihat tampilan "bahasa" berfungsi:

<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;" />

Ini memiliki beberapa keunggulan:

• Terlihat lebih baik
• lebih ringkas
• tidak ada konteks funky yang beralih antara tag HTML dan <%%>
• kata kunci yang mudah dimengerti yang cukup jelas (bahkan non-programmer bisa melakukan ini - bagus untuk paralelisasi)
• sebanyak mungkin logika dipindahkan kembali ke controller (atau model)
• tanpa HTML yang dihasilkan - sekali lagi, ini membuatnya sangat mudah bagi seseorang untuk datang dan tahu di mana harus gaya sesuatu, tanpa harus dipusingkan dengan Html. metode
• kode memiliki sampel teks di dalamnya yang dirender ketika Anda memuat tampilan sebagai HTML biasa di browser (sekali lagi, bagus untuk tata letak orang)

Jadi, apa sebenarnya yang dilakukan sintaks ini?

mvc: inner = "" - apa pun yang ada dalam tanda kutip akan dievaluasi dan HTML bagian dalam tag akan diganti dengan string yang dihasilkan. (Teks sampel kami akan diganti)

mvc: outer = "" - apa pun yang ada dalam tanda kutip akan dievaluasi dan HTML luar dari tag akan diganti dengan string yang dihasilkan. (Sekali lagi, teks sampel diganti.)

{} - ini digunakan untuk menyisipkan output di dalam atribut, mirip dengan <% =%>

mvc: if = "" - insde the qoutes adalah ekspresi boolean yang akan dievaluasi. Penutup if adalah tempat tag HTML ditutup.

mvc: selain itu

mcv: elseif = "" - ...

mvc: foreach

Sekarang, saya hanya bisa berbicara sendiri di sini:

IMO, jika Anda seorang mati-keras (apa pun) maka konversi bukan untuk Anda. Jika Anda menyukai WebForms, itu karena Anda dapat mencapai apa yang Anda butuhkan, dan itulah tujuan dari semuanya.

Bentuk web melakukan pekerjaan yang baik untuk mengabstraksi HTML dari pengembang . Jika itu tujuan Anda, tetap menggunakan Formulir Web. Anda memiliki semua fungsionalitas "klik dan seret" yang luar biasa yang telah membuat pengembangan desktop seperti sekarang ini. Ada banyak kontrol yang disertakan (ditambah banyak kontrol pihak ketiga) yang dapat menghasilkan fungsionalitas yang berbeda. Anda dapat menyeret "kisi" yang secara langsung dikaitkan dengan DataSource dari database Anda; ia datang dengan built-in-editing, paging, dll.

Sampai sekarang, ASP.NET MVC sangat terbatas dalam hal kontrol pihak ketiga. Jadi sekali lagi, jika Anda menyukai Rapid Application Development, di mana banyak fungsi terhubung untuk Anda, Anda sebaiknya tidak mencoba untuk dikonversi.

Dengan semua ini dikatakan, di sinilah ASP.NET bersinar: - TDD. Kode tidak dapat diuji, kata nuff.

• Pemisahan masalah. Itu adalah tulang punggung dari pola MVC. Saya sepenuhnya menyadari bahwa Anda dapat melakukannya di Formulir Web. Namun, saya suka struktur yang dipaksakan. Itu terlalu mudah di Formulir Web untuk mencampur desain dan logika. ASP.NET MVC memudahkan anggota tim yang berbeda untuk mengerjakan bagian aplikasi yang berbeda.

• Datang dari tempat lain: Latar belakang saya adalah CakePHP dan Ruby on Rails. Jadi, sudah jelas di mana bias saya berada. Ini hanya tentang apa yang membuat Anda nyaman.

• Kurva Belajar: Untuk memperluas poin terakhir; Saya benci ide "templating" untuk mengubah fungsionalitas elemen yang berbeda. Saya tidak suka fakta bahwa banyak desain yang dicapai dalam kode di belakang file. Itu satu hal lagi yang harus dipelajari, ketika saya sudah akrab dengan HTML dan CSS. Jika saya ingin melakukan sesuatu di "elemen" pada halaman, saya tetap di "div" atau "span", menampar ID di atasnya dan pergilah. Dalam Formulir Web saya harus meneliti bagaimana melakukan ini.

• Keadaan "Desain" Web Saat Ini: Perpustakaan Javascript seperti jQuery menjadi lebih umum. Cara Web Forms membuat ID Anda hanya membuat implementasi (di luar Visual Studio) lebih sulit.

• Lebih Banyak Pemisahan (Desain): Karena banyak desain disambungkan ke kontrol Anda, akan sangat sulit bagi desainer luar (tanpa Formulir Web) pengetahuan untuk bekerja pada proyek Formulir Web. Formulir Web dibangun untuk menjadi yang terakhir dan menjadi semua.

Sekali lagi, banyak alasan ini berasal dari ketidaktahuan saya dengan Formulir Web. Proyek Formulir Web (jika dirancang dengan benar) dapat memiliki "sebagian besar" manfaat dari ASP.NET MVC. Tapi itu peringatan: "Jika dirancang dengan benar". Dan itu hanya sesuatu yang saya tidak tahu bagaimana melakukannya di Formulir Web.

Jika Anda melakukan pekerjaan bintang di Formulir Web, Anda efisien dan bekerja untuk Anda, di situlah Anda harus tinggal.

Pada dasarnya, lakukan review cepat pada keduanya (cobalah untuk menemukan sumber yang tidak bias [semoga sukses]) dengan daftar pro dan kontra, evaluasi mana yang sesuai dengan tujuan Anda dan pilih berdasarkan itu.

Intinya, pilih jalan yang paling tidak resistan dan paling bermanfaat untuk memenuhi tujuan Anda. Formulir Web adalah kerangka kerja yang sangat matang dan hanya akan menjadi lebih baik di masa depan. ASP.NET MVC hanyalah alternatif lain (untuk menggambar di Ruby on Rails dan pengembang CakePHP seperti saya: P)

JSP Java EE tampak seperti ini ketika pertama kali diusulkan - kode skrip jelek.

Kemudian mereka menawarkan perpustakaan tag untuk membuatnya lebih HTML tag-ish. Masalahnya adalah siapa pun dapat menulis perpustakaan tag. Beberapa hasil adalah bencana, karena orang-orang menyematkan banyak logika (dan bahkan gaya) ke pustaka tag yang menghasilkan HTML.

Saya pikir solusi terbaik adalah JSP Standard Tag Library (JSTL). Ini "standar", tag-ish HTML, dan membantu mencegah orang untuk memasukkan logika ke halaman.

Manfaat tambahan adalah menjaga garis demarkasi antara desainer web dan pengembang. Situs bagus yang saya lihat dirancang oleh orang-orang dengan rasa estetika dan merancang untuk kegunaan. Mereka mengeluarkan halaman dan CSS dan meneruskannya ke pengembang, yang menambahkan bit data dinamis. Berbicara sebagai pengembang yang tidak memiliki hadiah ini, saya pikir kami memberikan sesuatu yang penting ketika kami meminta pengembang untuk menulis halaman web dari sup hingga kacang. Flex dan Silverlight akan mengalami masalah yang sama, karena tidak mungkin para desainer akan mengenal JavaScript dan AJAX dengan baik.

Jika .NET memiliki jalur yang mirip dengan JSTL, saya akan menyarankan agar mereka memeriksanya.

Saya pikir saya akan membagikan bagaimana contoh ini terlihat dengan mesin tampilan Razor baru yang mengkilap yang merupakan default sejak ASP .NET MVC 3.

@{ 
    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>
}

Ada masalah dengan itu?
Juga, Anda seharusnya tidak benar-benar menyatukan gaya CSS Anda, bukan? Dan mengapa Anda memeriksa nol di tiga tempat, bukan hanya dua? Ekstra divjarang sakit. Beginilah cara saya melakukannya:

<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>

Saya tidak dapat berbicara langsung dengan proyek ASP.NET MVC, tetapi secara umum kerangka kerja MVC mendominasi pengembangan aplikasi web karena

1. Mereka menawarkan pemisahan formal antara Operasi Database, "Logika Bisnis", dan Presentasi

2. Mereka menawarkan fleksibilitas yang cukup dalam tampilan untuk memungkinkan pengembang untuk mengubah HTML / CSS / Javascript mereka untuk bekerja di beberapa browser, dan versi masa depan dari browser tersebut

Ini bagian terakhir yang penting. Dengan Webforms, dan teknologi serupa, Anda mengandalkan vendor Anda untuk menulis HTML / CSS / Javascript untuk Anda. Ini hal yang kuat, tetapi Anda tidak memiliki jaminan bahwa versi Webforms saat ini akan berfungsi dengan browser web generasi berikutnya.

Itulah kekuatan pandangan. Anda mendapatkan kontrol penuh atas HTML aplikasi Anda. Kekurangannya adalah, Anda harus cukup disiplin untuk menjaga logika dalam pandangan Anda seminimal mungkin, dan menjaga kode templat sesederhana mungkin.

Jadi, itulah kompromi. Jika Webforms bekerja untuk Anda dan MVC tidak, maka tetap gunakan Webforms

Sebagian besar frustrasi saya dengan itu hanya tidak tahu bagaimana melakukan sesuatu dengan "benar". Sejak dirilis sebagai pratinjau, kita semua memiliki sedikit waktu untuk melihat sesuatu, tetapi mereka telah berubah sedikit. Pada awalnya saya benar-benar frustrasi tetapi kerangka tampaknya cukup bisa dilakukan untuk memungkinkan saya membuat UI yang sangat kompleks (baca: Javascript) cukup cepat. Saya mengerti bahwa Anda dapat melakukan ini dengan Webforms seperti yang saya lakukan sebelumnya, tetapi itu adalah rasa sakit yang sangat besar di pantat mencoba untuk membuat semuanya untuk membuat dengan benar. Banyak kali saya akhirnya menggunakan repeater untuk mengontrol output yang tepat dan akan berakhir dengan banyak kekacauan spaghetti yang Anda miliki di atas juga.

Dalam upaya untuk tidak memiliki kekacauan yang sama, saya telah menggunakan kombinasi memiliki domain, lapisan layanan, dan dto untuk mentransfer ke tampilan. Masukkan itu bersama dengan percikan, tampilan mesin dan itu menjadi sangat bagus. Butuh sedikit persiapan, tetapi begitu Anda berhasil, saya telah melihat langkah besar dalam kompleksitas aplikasi saya secara visual, tetapi sangat mudah untuk melakukan kode secara bijaksana.

Saya mungkin tidak akan melakukannya persis seperti ini, tetapi inilah contoh Anda:

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

Itu cukup mudah dirawat, dapat diuji, dan rasanya enak di sup kode saya.

Yang perlu diperhatikan adalah bahwa kode bersih itu benar-benar mungkin, tetapi ini adalah perubahan besar dari cara kami melakukan sesuatu. Saya pikir belum semua orang menikmatinya. Saya tahu saya masih mencari tahu ...

Buku karya Steve Sanderson yang baru-baru ini diterbitkan 'Pro ASP.NET MVC' [1] [2] dari Apress menyarankan alternatif lain - membuat ekstensi HtmlHelper khusus. Sampelnya (dari Bab 4 pada halaman 110) menggunakan contoh daftar halaman, tetapi dapat dengan mudah disesuaikan untuk situasi Anda.

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();
}

Anda akan menyebutnya dalam tampilan Anda dengan kode sesuatu seperti ini:

<%= 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

Saya berharap untuk melihat posting dari Phil Haack, tetapi tidak ada di sini jadi saya hanya memotong dan menempelkannya dari http://blog.wekeroad.com/blog/i-spose-ill-just-say-it-you-should -learn-mvc / di bagian komentar

Haacked - 23 April 2009 - Rob, Anda kerusuhan! :) Saya merasa lucu ketika orang menulis kode spaghetti di MVC dan kemudian berkata "lihat! Spaghetti!" Hai, saya juga bisa menulis kode spageti dalam Formulir Web! Saya bisa menulisnya di rails, PHP, Java, Javascript, tetapi tidak Lisp. Tetapi hanya karena saya belum bisa menulis apa pun di Lisp. Dan ketika saya menulis kode spaghetti saya tidak melihat piring saya dengan murung berharap untuk melihat makaroni. Poin yang sering dibuat orang ketika membandingkannya dengan ASP klasik adalah bahwa dengan ASP klasik orang cenderung untuk mencampur kekhawatiran. Halaman akan memiliki tampilan logika dengan penanganan input pengguna yang dicampur dengan kode model dan logika bisnis semuanya digabungkan menjadi satu. Itu tentang spageti! Menggabungkan semua kekhawatiran dalam satu kekacauan besar. Dengan ASP.NET MVC, jika Anda mengikuti polanya, Anda cenderung melakukannya. Ya, Anda mungkin masih memiliki sedikit kode dalam tampilan Anda, tetapi mudah-mudahan itu semua kode tampilan. Pola ini mendorong Anda untuk tidak memasukkan kode interaksi pengguna di sana. Masukkan ke dalam pengontrol. Masukkan kode model Anda dalam kelas model. Sana. Tanpa spageti. Ini Sushi O-Toro sekarang. :)

Saya juga; Saya akan menghabiskan waktu saya di Silverlight daripada ASP.NET MVC. Saya telah mencoba MVC 1.0 dan telah melihat rilis 2.0 Beta 1 terbaru beberapa hari yang lalu.

Saya (tidak bisa) merasakan bagaimana ASP.NET MVC lebih baik daripada webform. Nilai jual MVC adalah:

1. Unit (tes)
   
2. Pisahkan desain (tampilan) dan logika (pengontrol + model)
   
3. Tidak ada kondisi tampilan dan manajemen id elemen yang lebih baik
   
4. URL tenang dan banyak lagi ...

Tapi bentuk web, dengan menggunakan kode-belakang. Tema, Skin, dan Sumber Daya sudah sempurna untuk memisahkan desain dan logika.

Kondisi Tampilan: manajemen id klien datang pada ASP.NET 4.0. Saya hanya khawatir tentang tes unit, tetapi tes unit tidak cukup menjadi alasan untuk mengubah saya ke ASP.NET MVC dari webform.

Mungkin saya bisa mengatakan: ASP.NET MVC tidak buruk, tetapi webform sudah cukup.

Saya telah menggunakan MVC sejak Preview 3 keluar dan saat ini masih ada rasa sakit yang berkembang, itu membantu sedikit di bidang pengembangan tim. Cobalah meminta tiga orang bekerja pada satu halaman webforms dan Anda akan memahami konsep membenturkan kepala Anda di dinding. Saya dapat bekerja dengan pengembang yang memahami elemen desain pada halaman tampilan dan dewa Linq kami yang residen dalam membuat model bekerja sementara saya meletakkan semuanya dalam controller. Saya tidak pernah bisa berkembang di dunia di mana pemisahan kekhawatiran begitu mudah dicapai.

Nilai jual terbesar dari ASP.Net MVC - StackOverflow berjalan pada tumpukan MVC.

Yang sedang berkata ... kode Anda jauh lebih cantik daripada apa yang biasanya saya lakukan dengan halaman tampilan. Juga, salah satu orang yang bekerja sama dengan saya sedang mengerjakan membungkus penolong HTML ke dalam perpustakaan tag. Alih-alih <% = Html.RandomFunctionHere ()%> berfungsi seperti itu

<hh: fungsi acak />

Saya hanya berharap tim MVC dapat melakukannya di beberapa titik karena saya yakin mereka akan melakukan pekerjaan yang lebih baik.

Gunakan Pola Fasad untuk membungkus semua logika untuk semua data yang Anda butuhkan untuk ditampilkan dan kemudian menggunakannya sebagai generik Anda dalam pandangan Anda dan kemudian .... tidak ada lagi kode spaghetti. http://en.wikipedia.org/wiki/Design_pattern_(computer_science)

Jika Anda memerlukan bantuan lebih lanjut cgardner2020@gmail.com

Implementasi ASP.NET MVC mengerikan. Produk polos menyebalkan. Saya telah melihat beberapa demo dan saya malu dengan MSFT ... Saya yakin orang-orang yang menulisnya lebih pintar daripada saya, tetapi hampir seolah-olah mereka tidak tahu apa Model-View-Controller itu .

Satu-satunya orang yang saya kenal yang mencoba menerapkan MVC adalah orang-orang yang suka mencoba hal-hal baru dari MSFT. Dalam demo yang saya lihat, presenter memiliki nada minta maaf ...

Saya penggemar berat MSFT, tetapi saya harus mengatakan bahwa saya tidak melihat alasan untuk repot dengan implementasi MVC mereka. Baik menggunakan Formulir Web atau menggunakan jquery untuk pengembangan web, jangan pilih kekejian ini.

EDIT:

Maksud dari pola desain arsitektur Model-View-Controller adalah untuk memisahkan domain Anda dari presentasi dari aturan bisnis. Saya telah berhasil menggunakan pola di setiap proyek Formulir Web yang telah saya laksanakan. Produk ASP.NET MVC tidak cocok dengan pola desain arsitektur yang sebenarnya.