Kapan harus memilih ASP.NET WebForms daripada MVC

Saya tahu bahwa Microsoft telah mengatakan

ASP.NET MVC bukan pengganti untuk WebForms.

Dan beberapa pengembang mengatakan WebForms lebih cepat berkembang daripada MVC. Tapi saya percaya kecepatan pengkodean turun ke tingkat kenyamanan dengan teknologi jadi saya tidak ingin ada jawaban dalam nada itu.

Mengingat bahwa ASP.NET MVC memberi pengembang lebih banyak kontrol atas aplikasi mereka, mengapa WebForms tidak dianggap usang? Atau, kapan saya harus menyukai WebForms daripada MVC untuk pengembangan baru?

Bentuk web vs. MVC tampaknya menjadi topik hangat saat ini. Semua orang yang saya kenal menyebut MVC sebagai hal hebat berikutnya. Dari sedikit berkecimpung di dalamnya, tampaknya ok, tapi tidak, saya tidak berpikir itu akan menjadi akhir dari webforms.

Alasan saya, dan alasan mengapa formulir web akan dipilih daripada MVC, lebih berkaitan dengan perspektif bisnis daripada apa yang lebih baik dari yang lain.

Waktu / uang adalah alasan terbesar mengapa formulir web akan dipilih daripada MVC.

Jika sebagian besar tim Anda mengetahui formulir web, dan Anda tidak punya waktu untuk mempercepatnya di MVC, kode yang akan dihasilkan mungkin tidak berkualitas. Mempelajari dasar-dasar MVC kemudian melompat masuk dan melakukan halaman rumit yang perlu Anda lakukan adalah hal yang sangat berbeda. Kurva pembelajaran tinggi sehingga Anda perlu memasukkannya ke dalam anggaran Anda.

Jika Anda memiliki situs web besar yang ditulis semua dalam formulir web, Anda mungkin lebih cenderung membuat halaman baru dalam bentuk web sehingga Anda tidak memiliki dua jenis halaman yang sangat berbeda di situs Anda.

Saya tidak mengatakan ini pendekatan semua atau tidak sama sekali di sini, tetapi itu membuat kode Anda lebih sulit untuk dipertahankan jika ada perpecahan keduanya, terutama jika tidak semua orang di tim terbiasa dengan MVC.

Perusahaan saya baru-baru ini melakukan tiga halaman pengujian dengan MVC. Kami duduk dan mendesainnya. Satu masalah yang kami hadapi adalah sebagian besar layar kami memiliki fungsi Lihat dan Edit pada halaman yang sama. Kami akhirnya membutuhkan lebih dari satu formulir di halaman. Tidak masalah, kecuali kalau kita tidak akan menggunakan halaman utama kita. Kami harus mengubah sehingga halaman formulir web dan halaman MVC dapat menggunakan masterpage yang sama untuk tampilan dan rasa yang sama. Sekarang kita memiliki lapisan tambahan untuk bersarang.

Kami perlu membuat struktur folder yang sama sekali baru untuk halaman-halaman ini sehingga mengikuti pemisahan MVC yang tepat.

Saya merasa ada terlalu banyak file untuk 3 halaman, tetapi itu adalah pendapat pribadi saya.

Menurut pendapat saya, Anda akan memilih formulir web daripada MVC jika Anda tidak memiliki waktu / uang untuk berinvestasi dalam memperbarui situs Anda untuk menggunakan MVC. Jika Anda melakukan pendekatan setengah arsen untuk ini, itu tidak akan lebih baik dari bentuk web yang Anda miliki sekarang. Lebih buruk lagi, Anda bahkan dapat mengatur teknologi ini untuk kegagalan di perusahaan Anda jika itu kacau, karena manajemen atas mungkin melihatnya sebagai sesuatu yang lebih rendah daripada apa yang mereka ketahui.

Saya mengembangkan aplikasi ASP .Net WebForms selama 3 tahun, dan setelah satu hari melakukan tutorial MVC, saya dijual. MVC hampir SELALU solusi yang lebih baik. Mengapa?

• Lifecylce halaman lebih sederhana dan lebih efisien
• Tidak ada yang namanya kontrol selain kontrol html. Anda tidak perlu men-debug output Anda untuk melihat apa yang dihasilkan oleh ASP .Net.
• ViewModels memberi Anda kekuatan luar biasa dan meniadakan kebutuhan untuk melakukan pengikatan kontrol manual dan menghilangkan banyak kesalahan terkait pengikatan.
• Anda dapat memiliki beberapa formulir di satu halaman. Ini adalah batasan serius dari WebForms.
• Web tidak bernegara dan MVC cocok dengan arsitektur web lebih dekat. Bentuk web memperkenalkan status dan bug yang Anda miliki dengan memperkenalkan kondisi tampilan. ViewState otomatis dan berfungsi di latar belakang, sehingga tidak selalu berperilaku seperti yang Anda inginkan.
• Aplikasi web perlu bekerja dengan ajax hari ini. Tidak dapat diterima untuk memuat halaman penuh lagi. MVC membuat ajax jadi jauh lebih baik, lebih mudah dan lebih efisien dengan JQuery.
• Karena Anda dapat memiliki beberapa formulir pada halaman, dan karena arsitektur didorong oleh panggilan ke url, Anda dapat melakukan hal-hal yang funky seperti ajax memuat formulir yang berbeda, seperti formulir edit ke halaman Anda saat ini menggunakan JQuery. Setelah Anda menyadari apa yang dapat Anda lakukan, Anda dapat melakukan hal-hal luar biasa dengan mudah.
• ASP .Net WebForms bukan hanya abstraksi atas html, tetapi juga sangat kompleks. Terkadang Anda akan mendapatkan bug aneh dan berjuang untuk itu lebih lama dari yang seharusnya. Dalam banyak kasus Anda benar-benar bisa melihat apa yang salah tetapi Anda tidak dapat melakukan apa-apa. Anda akhirnya melakukan solusi aneh.
• WebForms tidak membuat teknologi yang baik untuk desainer. Desainer sering suka bekerja dengan html secara langsung. Di MVC itu adalah pemandangan, di WebForms itu adalah setengah hari kerja.
• Sebagai platform web berkembang WebForms cepat tidak akan mengikuti. Tidak mengetahui tag atau fitur baru HTML5, masih akan membuat hal yang sama kecuali Anda mendapatkan (sering) kontrol pihak ke-3 yang mahal atau menunggu Microsoft untuk mengeluarkan pembaruan.
• Kontrol di WebForms membatasi Anda dalam banyak hal. Di MVC Anda bisa mengambil perpustakaan JQuery dan mengintegrasikannya ke dalam template Anda.

Saya tahu beberapa masalah di atas telah ditangani sampai batas tertentu ketika WebForms berevolusi, tapi itu adalah pengalaman asli saya. Semua dalam semua, saya akan merasa sangat sulit untuk menemukan kasus bisnis untuk WebForms kecuali proyek sudah menggunakannya.

Saya mengirim email kepada Scott Guthrie , seorang pakar MVC di Microsoft. Dan mungkin orang yang paling memenuhi syarat untuk menjawab pertanyaan ini. Dia cukup baik untuk menjawab:

"Pelanggan yang berbeda mencari pendekatan pemrograman yang berbeda, dan sangat menyukai WebForms dan menganggapnya hebat. Yang lain menyukai MVC dan menganggapnya hebat. Itulah sebabnya kami berinvestasi pada keduanya."

Jadi, bagi saya ini mengatakan bahwa ini bukan masalah teknis. Ini lebih merupakan "masalah lunak", jika Anda mau. Salah satu preferensi pribadi. Ini sejalan dengan apa yang beberapa dari Anda katakan.

Terima kasih atas semua jawabannya.

Ini adalah pertanyaan basi dengan banyak jawaban tetapi tidak ada jawaban yang saya harapkan terdaftar.

Jawaban singkatnya adalah:

• Gunakan ASP.NET MVC jika Anda berniat membangun aplikasi web dengan benar dengan konvensi pemrograman modern dan pola yang dianut industri untuk platform ASP.NET. Di sisi bawah Anda akan diharapkan untuk mengetahui bagaimana HTML dan sumber daya sisi klien (Javascript, CSS) bekerja serta meningkatkan pada pola pikir pemrograman MVC yang memiliki kurva belajar yang curam tetapi mencapai akhir yang tiba-tiba begitu dipahami.
• Gunakan Formulir Web ASP.NET jika Anda menggunakan atau ingin menggunakan pendekatan GUI- sentris, RAD (Pengembangan Aplikasi Cepat) , seret-dan-jatuhkan untuk membuat prototipe sesuatu dengan sangat cepat, misalnya perilaku tombol-tekan / kisi-kisi data yang terhubung dalam 15 menit, dan solusinya tidak dimaksudkan untuk menjadi sesuatu yang didukung oleh pengembang. Atau, Gunakan ASP.NET Web Forms jika Anda memiliki latar belakang dalam pengembangan GUI atau Windows Forms dan Anda ingin mentransfer pengetahuan Anda ke Web.

Tetapi untuk melihat ini dengan benar, Anda harus memahami sejarah masing-masing.

Formulir Web ASP.NET adalah jawaban Microsoft untuk mereka yang telah membangun aplikasi web dinamis menggunakan kontrol Visual Basic 6 ActiveX, VB6 DLL di server, dan ASP Classic. Pada saat itu, pengembangan web menggunakan alat-alat Microsoft ini benar-benar berantakan. Seiring dengan keseluruhan .NET Framework yang merupakan output dari Microsoft pada dasarnya akan kembali ke papan gambar tentang bagaimana melakukan pemrograman bisnis yang produktif pada tumpukan Windows, ASP.NET Web Forms, pada masanya, menakjubkan dan indah.

Seluruh pendekatan adalah untuk memberikan pengembang yang terbaik dari kedua dunia dari sesuatu yang sangat mirip dengan pengembangan aplikasi Windows, tetapi dengan kekuatan layanan internet. Idenya adalah bahwa, seperti halnya VB6 / WinForms "Formulir" (jendela) juga halaman web adalah formulir (seperti jendela, lihat) , dan pada formulir itu Anda dapat menyeret-dan-jatuhkan label, kotak teks, kisi data, tombol, dan hal-hal lain yang biasa digunakan oleh pengembang GUI VB / WinForms.

Untuk membuat tombol melakukan sesuatu, setelah menyeret-dan-menjatuhkan Anda cukup klik dua kali pada desainer dan boom Anda berada di editor kode, memberi tahu formulir apa yang harus dilakukan ketika peristiwa "klik" itu terjadi. Ini persis bagaimana pengembang Windows GUI menciptakan perangkat lunak menggunakan GUI tooling VB6 dan alat yang bersaing, kecuali sekarang kode mengeksekusi di server! Wow!

Ini adalah teknologi tahun 2002. Luar biasa dan indah pada masanya sebagai jawaban untuk solusi GUI yang memungkinkan internet untuk pengembangan RAD , itu membawa rasa kekuatan ke dunia yang berantakan dari para pengembang perangkat lunak yang memiliki tujuan bisnis yang harus mereka capai.

Sayangnya, model pemrograman ini sangat menekankan metafora pemrograman Windows GUI sehingga membawa serta beban detail implementasi yang diperlukan, semua beban pembebanan yang diperlukan untuk mengakomodasi siklus hidup acara dan menyimpan rincian jelek dari HTML sederhana dan skrip yang akan dihasilkan komponen dan kontrol seret dan lepas ini. Dan pada akhirnya, pengembang yang mendukung aplikasi nyata pasti harus menggali lebih dalam komponen-komponen ini atau menulis sendiri, dan akibatnya mereka akan bertempur dengan infrastruktur ini, pertempuran yang akan meninggalkan tumpukan tumpukan demi tumpukan, menarik rambut, dan air mata.

Cadangkan. Cuci tanganmu. Mari kita lihat masalah bisnis lagi. Apa tujuan bisnis kita?

Kita perlu membangun dan mengelola aplikasi web . Kendala kami adalah bahwa kami memiliki World Wide Web, yang duduk di HTTP, HTML, Javascript, dan CSS, dan di server kami memiliki aturan bisnis, database, dan beberapa bahasa pemrograman yang hebat (misalnya C #). Apakah kita benar-benar membutuhkan metafora Windows GUI ini untuk mendorong metodologi pengembangan kita? Mengapa kita tidak bisa hanya fokus pada masalah aplikasi dan menghapus metafora GUI?

Di sinilah ASP.NET MVC masuk. Ini dimulai oleh pemberontakan pengembang yang menyebut diri mereka "Alt.Net" yang ingin kembali ke prinsip pengembangan perangkat lunak yang tepat dan murni. Tidak ada lagi masalah, hanya fokus pada tujuan bisnis dan praktik terbaik perangkat lunak.

Apa yang sebenarnya diterjemahkan dalam hal ini adalah:

1. Pemisahan masalah . Sebagai contoh, komponen data tidak perlu tahu bagaimana data akan diberikan, juga markup tampilan tidak boleh dibebani dengan detail konfigurasi koneksi database, dan dengan cara ini pengembang dapat fokus pada bidang yang menjadi perhatiannya ketika mengedit dan kode pengujian.
2. Eksposur dan dukungan penuh untuk eksposur pada seluk beluk HTML dan sumber daya terkait . Dalam Formulir Web, HTML terselip, pengembang tidak suka repot-repot dengan itu. Dalam ASP.NET MVC, pengembang agak didorong untuk mengelola detail tersebut; sebenarnya itu suatu keharusan. Keuntungan di sini adalah bahwa pengembang dapat kembali belajar untuk menghargai semantik bersih dari HTML, CSS, dan script, dan bekerja dengan itu daripada melawannya.
3. Testabilitas benda-benda bisnis . Pengontrol dan model jauh lebih cocok untuk pengujian unit program, sehingga implementasi dapat divalidasi untuk memenuhi tujuan bisnis, dan perubahan dapat diverifikasi sehingga tidak akan pecah. Dengan Formulir Web sulit untuk menguji karena komponen tidak dirancang untuk diuji secara individual dan seluruh hasil pengembangan berputar di sekitar formulir halaman dan siklus hidup acara mereka dengan kotoran logika bisnis dan logika presentasi yang sangat terkait.

Perhatikan bahwa HTML sudah menjadi bahasa markup tingkat sangat tinggi, seperti halnya Javascript bahasa pemrograman tingkat tinggi. Seluruh cerita akan berbeda jika kita berurusan dengan bahasa Majelis dan C.

Memperluas pada # 2, kemudian, tujuan lain dari ASP.NET MVC adalah untuk memungkinkan pengembang untuk mengatur rincian front-end dari bagian 'tampilan' dari solusi mereka dan mengambil keuntungan dari fondasi kaya yang dibangun oleh industri lainnya. platform klien front-end.

Anda akan menemukan bahwa pengembang ASP.NET MVC merasa betah menggunakan perpustakaan Javascript yang kaya dan teknik templating sisi klien tanpa berkelahi dengan arsitektur sisi server. Ini pada awalnya bukan kasus dengan ASP.NET Web Forms, karena Formulir Web tidak ingin Anda melihat HTML atau skrip sama sekali, kecuali jika Anda benar-benar harus , dalam hal ini, berhati-hatilah, itu bukan untuk pingsan dari hati.

Saya seorang konversi lengkap dan total ke ASP.NET MVC dan belum melihat ke belakang, yang mengatakan saya masih harus mempertahankan beberapa aplikasi WebForms yang sangat besar. Inilah pendapat saya:

WebForms
Gunakan ini ketika Anda melakukan beberapa pekerjaan berat yang serius untuk dilakukan dengan kisi-kisi. Kontrol kisi sangat bagus ketika Anda memiliki dataset sederhana yang cocok dengan baik dalam format tabel dan Anda ingin memberikan cara sederhana bagi pengguna untuk memperbarui catatan. Ya, saya tahu bahwa MVC 4 memiliki daftar tipe Ajax yang benar-benar manis yang dapat Anda gunakan yang bekerja sangat baik, tetapi, dalam bisnis kami, kami sering perlu menjalankan sesuatu kemarin dan kisi-kisi model lama yang bagus berfungsi dengan baik dan pengguna senang menjadi dapat tab di grid dengan gembira. Bagi saya itu benar-benar hal terbaik tentang WebForms bagi saya; tapi, seperti Ryanmenunjukkan WebForms bisa menjadi kekacauan waktu yang besar karena Anda memainkan kedua sisi pagar dari file kode-balik yang bagus. Ini bisa berupa mawar dan duri pada saat yang sama untuk menjaga semua jenis pengontrol Anda tetap terhubung dengan pandangan Anda.

MVC
Gunakan ini ketika Anda benar-benar ingin menggulung sendiri dan Anda memiliki kesempatan untuk memulai aplikasi dari awal. Memiliki aplikasi MVC yang terdefinisi dengan jelas sedikit lebih sulit untuk memulai, tetapi manfaatnya dalam perawatan lebih besar daripada biaya pemasangan awal. Jika Anda ingin melakukan interaksi Ajax yang menarik, lebih suka menulis model Anda dengan kode, seperti url bersih dan rute, dan dapat mengontrol seluruh aliran aplikasi Anda maka ini jelas cara yang harus dilakukan. Dibutuhkan beberapa membiasakan diri pada awalnya, tetapi saya pikir itu pilihan yang lebih baik untuk aplikasi greenfield.

Kesimpulannya, bagi saya, turun ke grid dan! Grid. :)

Pengalaman saya:

• Menulis proyek CakePHP selama satu tahun.
• Menyelesaikan proyek Webform berukuran sedang selama enam bulan.
• Bekerja pada proyek Windows Forms selama tiga tahun.

Setelah pengalaman itu, saya mencoba menulis aplikasi lain menggunakan webforms, dan merasa frustrasi setelah berjuang selama sekitar satu hari dengan bagaimana webforms berusaha untuk melindungi pengembang dari kenyataan bahwa mereka sedang mengembangkan aplikasi yang menggunakan html, javascript dan css.

Saya kemudian mencoba MVC, dan memiliki lebih banyak kontrol langsung terhadap output (dan beberapa pengalaman dengan paradigma MVC dari CakePHP) saya dapat menyelesaikan aplikasi sederhana persis seperti yang saya inginkan dalam waktu sekitar 1/2 hari.

Ketersediaan kerangka kerja UI yang kuat seperti jQuery sangat menghilangkan daya tarik untuk menyerahkan kontrol langsung terhadap output demi menggunakan komponen UI yang sering dibangun sebelumnya yang besar.

Saya lebih suka formulir web karena latar belakang saya adalah pengembangan windows.

Kecepatan pengembangan adalah masalah utama, dan saya dapat dengan mudah memberikan masalah kepada seseorang di India untuk memperbaiki semalam dengan formulir, juga, jika saya memiliki masalah kecepatan pada halaman, buku yang sangat bagus tentang kecepatan asp.net sangat berguna (Rick Kiessig adalah pria).

bentuk web adalah untuk ex windows orang mvc adalah untuk orang web

tetapi, di dunia modern, di mana Rick telah menulis buku yang luar biasa, dengan server yang meningkatkan kecepatan coders harian dan murah di India, well, webforms memiliki keunggulan.

2 sen saya adalah untuk selalu menggunakan ASP.NET MVC untuk proyek-proyek baru jika Anda memiliki opsi. Menurut pendapat saya, formulir web bukan cara yang baik untuk mengembangkan aplikasi web, titik.

Saya pikir mengabstraksi REST dasar adalah buruk, seluruh model postback buruk, cara html / css diserahkan dengan ketergantungan pada editor GUI buruk, penekanan pada hal-hal seperti penyihir dan GUI untuk mengatur semuanya buruk, URL jelek.

Saya telah membaca semua jawaban dan merasa pengalaman pribadi saya akan menambahkan sesuatu ke jawaban di atas.

3-4 tahun yang lalu, saya mengembangkan 2-3 proyek situs web menggunakan Webforms. Sekitar waktu itu, MVC tidak ada atau saya tidak pernah mendengarnya. Pengembangannya alami (saya datang dari pengembangan Win-form tanpa pengalaman pengembangan web sebelumnya) cepat untuk saya, karena saya tidak perlu belajar HTML secara detail dan kontrol web banyak membantu (banyak sekali, itu membuat hidup lebih mudah) .

Sekarang, setelah sekian lama, saya tidak mengerjakan proyek web apa pun sampai saat ini dan hanya membangun beberapa aplikasi windows menggunakan WPF.

Beberapa hari yang lalu saya punya ide untuk sebuah situs web dan berpikir untuk mengembangkannya: kali ini di MVC (karena ini berbicara di mana-mana, selain itu saya perlu belajar juga, jadi saya memilih MVC). Proyek ini masih dalam tahap pengembangan, karena saya masih belajar dan membangun bersama.

Jadi, perbedaan utama yang saya temukan antara keduanya adalah sebagai berikut: -

• Untuk seseorang yang datang dari pengembangan windows, formulir Web akan selalu menguntungkan. Kurva belajar Asp.net untuk pengembang windows agak curam

• Untuk seseorang yang datang dari pengembangan web di beberapa teknologi lain, MVC akan disukai karena mengolok-olok yang terbaru dari mereka semua.

• Pengembangan lebih mudah dan lebih bersih di MVC jika Anda dilengkapi dengan pengetahuan yang baik tentang HTML dan CSS

• Penempatan masih menjadi masalah. Dalam formulir web, seseorang hanya perlu melakukan salin dan tempel. Tapi, ini membutuhkan beberapa hal yang harus dilakukan.

Singkatnya, keduanya akan tinggal di sini sebentar.

Saya belum melihat pertimbangan ini diajukan di antara 15 jawaban yang ada untuk utas ini, tapi saya pikir ini layak dipertimbangkan.

Dari pengalaman saya, Formulir Web lebih mirip dengan Formulir Win dan WPF daripada MVC. Mengingat hal ini, saya pikir orang mungkin mempertimbangkan untuk memilih Formulir Web ketika tim memiliki pengalaman paling banyak dalam teknologi semacam itu, atau ketika proyek Formulir Web akan mengirimkan antarmuka ke set data yang sama dengan Formulir Menang yang ada (atau dikembangkan secara bersamaan) atau Proyek WPF. Melakukan hal itu memungkinkan pengembang untuk menyeberang antar proyek lebih mudah, karena logika aplikasi mungkin sangat mirip antara keduanya.

Sebagai jawaban lain telah menunjukkan, pengembangan kerangka kerja MVC lebih mirip dengan pengembangan web di Ruby, PHP, Python dll daripada rekan-rekan Microsoft; jadi tentu saja pilihan MVC dapat dipengaruhi oleh pengalaman tim di bidang-bidang tersebut, bersama dengan faktor-faktor yang diajukan dalam jawaban lain.

Alasan kami untuk tidak pergi ke MVC beberapa tahun yang lalu adalah karena teknologi yang belum matang dari Microsoft. Selama beberapa tahun terakhir kita sekarang berada pada versi yang lebih matang (4) dan MS tampaknya telah berhasil ke mana mereka akan pergi dengan ini. Namun, kami masih enggan mengembangkan aplikasi LOB utama menggunakan MVC karena fitur yang ingin kami gunakan dalam versi 4 memerlukan server windows 2012 (re soket web melalui IIS8). Saya rasa dalam 1 tahun lagi kita akan lebih menerima MVC karena mudah-mudahan lebih banyak kontrol pihak ketiga akan tersedia, teknologinya telah diselesaikan, dan kita akan memiliki infrastruktur untuk mendukungnya.

Keputusan ini tergantung pada preferensi Anda, pada permintaan Anda atau bahkan pada pengetahuan dan pengalaman Anda.

Waktu untuk pelatihan belajar MVC atau waktu untuk mendapatkan pengiriman. Semua hal ini penting untuk memilih satu atau beberapa pendekatan lain.

Bukankah yang satu lebih baik dari yang lain, hanya baik pendekatan atau kerangka kerja memiliki pro dan kontra.

Secara pribadi saya menyukai MVC 3, saya sarankan Anda untuk mencoba mendapatkan pengalaman Anda sendiri, tetapi saya perlu mengatakan bahwa program di MVC adalah cara yang bersih, menyenangkan, fleksibel, dapat diperpanjang, aman dan terstruktur.

Salam,

Satu-satunya alasan mengapa saya akan memilih WebForms daripada MVC adalah karena Anda memiliki lebih banyak kontrol UI pihak ke-3 untuk WebForms daripada MVC. Saya memilih MVC karena saya bekerja terlalu banyak dengan WebForms dan saya ingin bekerja dengan sesuatu yang baru / baru, tetapi masih dari MS shop :)

Pada dasarnya, tidak ada yang mencegah Anda untuk mematikan kondisi tampilan di WebForms dan menggunakan ViewModels dan jika / untuk loop, bukan model mengikat dan kontrol sisi server.

Apakah ini kode WebForms atau MVC:

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

Satu-satunya batasan yang saya temukan di WebForms adalah bahwa jika Anda menggunakan Dependency Injection / Inversion of Control, Anda tidak dapat memiliki injeksi konstruktor karena halaman WebForms harus memiliki konstruktor tanpa parameter, jadi Anda harus menggunakan injeksi properti. Apakah ini benar-benar masalah besar?

ASP.NET MVC benar-benar merupakan jawaban untuk Ruby, dan cara baru, trendy, dan (IMO) yang lebih baik untuk memisahkan browser (klien) dari server sebanyak mungkin.

ASP.NET Webforms memberi Anda banyak kendali atas klien dari sisi server, dengan akses langsung ke hampir semuanya. Pada dasarnya pandangan dan pengontrol Anda adalah satu dalam yang sama, yang memberi Anda banyak daya, dan sering kali banyak kekacauan.

ASP.NET MVC memisahkan tampilan dan pengontrol dengan melepaskan kopling ketat dari file .aspx dan file .aspx.cs yang menyertainya dalam format web.

Pada dasarnya, perbedaannya adalah Anda memiliki lebih banyak (biasanya semua) dari pemrosesan untuk menampilkan data ke file tampilan, dan meninggalkan logika bisnis dan sisanya di controller, menjaga keduanya lebih bersih dengan konvensi, tetapi juga dengan lebih sedikit akses ke masing-masing selain memungkinkan formulir web.

Menurut pendapat saya, mereka cukup terkait dan memiliki kemampuan yang kira-kira sama dengan yang seharusnya.

Pengembang WebForms yang hebat dapat menghasilkan produk yang sama kuatnya dengan pengembang MVC yang hebat. Tetapi pengembang WebForms yang hebat yang mencoba memaksakan dirinya untuk mengadopsi MVC akan gagal. Hal yang sama berlaku untuk pengembang MVC yang hebat memberikan WebForms kesempatan.

Mereka bukan entitas yang sepenuhnya terpisah, dan selama Microsoft terus mendukung keduanya, saya yakin Anda akan terus melihat kelompok campuran pengembang luar biasa untuk masing-masing.

Ini semua tentang pilihan pribadi, dengan asumsi kita semua mahir dengan teknologi yang kita gunakan. Saya telah menggunakan pendekatan desain WebForms selama bertahun-tahun, dan saya harus mengatakan bahwa satu-satunya downside adalah bahwa karena pendekatannya yang sederhana, banyak orang tidak meluangkan waktu untuk menggali kemampuannya yang luas.

Saya baru-baru ini menggunakan MVC untuk menyelesaikan sebuah proyek, dan walaupun saya sangat menyukai pendekatan desain untuk pengembangan aplikasi (yang memberi Anda lebih banyak kontrol, membersihkan url, SOC, dll), sebenarnya tidak banyak yang disediakannya, yang tidak bisa dilakukan WebForms. Faktanya, kemunculan jQuery dan cara kerjanya dengan WebForms (dan juga MVC) telah membuat argumen ini kurang menjadi masalah. Dan ketika orang berbicara tentang pemisahan kekhawatiran sebagai keunggulan MVC dibandingkan MVP, saya bertanya kepada mereka seberapa banyak mereka tahu tentang pemrograman Berorientasi Objek dan seberapa banyak mereka menggunakan prinsip abstraksi dan polimorfisme.

Saat ini saya merasa nyaman menggunakan kedua teknologi dan saya memilih berdasarkan situasi. Terus terang, itu terserah Anda, tetapi kebenarannya tetap bahwa tidak semua orang mengambil waktu mereka untuk mempelajari secara mendalam apa yang mampu dilakukan teknologi tertentu.

Ketika dihadapkan dengan masalah pemrograman saya sering mencari jawaban di web. Bentuk web memiliki banyak informasi / komponen untuk melakukan apa saja. Dalam MVC karena lebih sedikit sumber online dan lapisan-lapisan abstraksi yang diperlukan untuk membuat sesuatu berfungsi, telah membatasi hal-hal yang pernah saya lakukan. Total MVC membunuh produktivitas saya sebagai pengembang sementara dengan Webforms tidak. Jadi untuk saat ini saya tetap menggunakan webforms sampai MVC telah cukup matang untuk menggantinya.

Yah, WebForms memiliki lebih banyak sumber belajar yang tersedia (hanya karena fakta bahwa itu lebih tua) dan dengan demikian programmer baru yang tidak "tahu" akan lebih mungkin menemukan informasi mengenai teknologi yang lebih tua ini dibandingkan dengan hal-hal yang lebih baru seperti MVC .

Pemrogram senior / berpengalaman lebih tua dan akan lebih mahir dalam teknologi yang lebih tua karena fakta bahwa mereka telah diprogram di dalamnya lebih lama daripada yang mereka miliki di yang lebih baru.

Kecuali Anda dapat menghabiskan uang dan upaya untuk membuat orang-orang Anda mahir dalam MVC seperti halnya mereka dalam aplikasi WebForms, Anda pasti akan mencoba dan menunda peningkatan ke platform baru selama mungkin.

Jadi itu menyajikan beberapa masalah logistik: Apakah manfaat MVC lebih besar daripada biaya dalam hal kualitas yang lebih rendah dan waktu penyebaran? Jika saya memiliki situs yang sepenuhnya ditulis dalam WebForms, apakah akan sepadan dengan usaha dan uang untuk mengintegrasikan MVC ke dalamnya?

Seperti yang dinyatakan oleh komentator sebelumnya, MVC juga mencegah Anda mencapai level antarmuka yang sama dengan pengontrol seperti halnya Anda dapat menggunakan WebForms. Meskipun saya semua untuk sisi "Menjaga agar pengguna tidak memasukkan / mempelajari hal-hal", masih bisa menjadi masalah yang tidak masuk akal bagi tim untuk menggunakan / mengimplementasikan program yang secara fanatik berpegang pada paradigma itu untuk semua yang mereka tulis.

Saya pikir kesenjangan antara kedua teknologi ini tidak selebar dulu.

• Formulir web dapat menggunakan mesin perutean yang digunakan MVC (atau sesuatu yang sangat mirip).
• Pengelola skrip dapat menggabungkan skrip, memuat dari CDN, dan bahkan menunda pemuatan skrip.

Untuk langsung menjawab pertanyaan Anda, saya pikir itu tergantung pada preferensi dan / atau apa proyeknya. Mereka berdua mengambil pendekatan pembangunan yang sangat berbeda. Secara pribadi saya telah bekerja bergerak menuju MVC, tetapi masih menikmati bekerja dengan Webforms. Saya pikir jawaban untuk apakah Anda harus menggunakan MVC atau Webform adalah bagi Anda untuk memutuskan melalui mengalami kedua teknologi.