Kapan harus memilih ASP.NET WebForms daripada MVC


189

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?


57
@Darknight: \ itu sangat bias dan salah. MVC bukan untuk aplikasi CRUD sederhana. Saya berpendapat WebForms adalah untuk aplikasi CRUD generik (yaitu database -> beberapa kontrol grid yang mengkilap).
Raynos

17
@Darknight apa pun yang membuat Anda bahagia -> jika Anda suka WebForms menjadi gila dengan itu;)
Raynos

16
@Darknight Anda jelas memiliki pemahaman yang buruk tentang MVC jika ini pendapat Anda ... Ada beberapa situs besar yang dibangun dengan MVC ... lakukan penelitian, Pak.
Robotsushi

31
IMO, jangan pernah menggunakan formulir web saat Anda dapat menggunakan MVC sebagai gantinya.
scottschulthess

10
Saya bukan orang yang bisa berbicara jadi ini hanya pendapat saya. Setelah membaca sebagian besar jawaban saya sampai pada kesimpulan bahwa jawabannya tidak pernah sama sekali. MVC luar biasa dan satu-satunya kekurangan yang saya temukan adalah saya terus melihat ;di halaman web saya (Jika Anda baru memulai dengan Razor, Anda akan mendapat lelucon).
MasterMastic

Jawaban:


105

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.


14
Ini jawaban yang bagus. Saya memberi Anda +1 karena pengalaman pribadi Anda dihargai. Tapi, ini gagal karena kurangnya pengalaman / keahlian dari para pengembang yang saya minta hindari. Saya tidak yakin bahwa Microsoft akan memilih untuk tidak menandai teknologi yang usang hanya karena takut kurva belajar untuk MVC. Mungkin ini masalahnya, tapi saya belum yakin.
P.Brian.Mackey

6
@ P.Brian.Mackey - Saya tidak mengatakan bahwa pengembangan formulir lebih cepat daripada MVC. Anda diminta untuk tidak membantahnya. Berdebat waktu dan uang untuk melatih staf Anda adalah argumen yang berbeda. MS tidak akan menandai formulir web yang usang karena satu alasan besar: Klien perusahaan telah menghabiskan bertahun-tahun mengembangkan klien web dalam formulir web dan tidak akan terlihat ramah karena harus menginvestasikan waktu dan uang untuk memperbarui.
Tyanna

16
@ Raynos - Jika semua orang di tim mahir dalam MVC, dan perusahaan Anda memulai proyek baru, maka satu-satunya alasan saya bisa melihat seseorang memilih formulir web adalah pilihan pribadi.
Tyanna

3
Saya kenal kedua teknologi itu secara intim. Semua proyek web saya selesai dengan MVC dan bekerja di perusahaan tempat saya bebas berkuasa untuk melakukan apa pun yang merupakan pendekatan terbaik. Saya selalu memilih MVC.
Robotsushi

6
Saya mulai dengan Webforms dan begitu saya menemukan MVC saya beralih ke itu. Saya tidak tahu bagaimana orang dapat mempertahankan formulir web. Siklus hidup halaman dan satu formulir untuk seluruh halaman? Apakah kamu bercanda? Sitebuilder Yahoo mungkin adalah pelanggan yang dituju, tetapi bahkan mereka tidak menginginkan sampah itu.
The Muffin Man

188

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.


6
+1 untuk menunjukkan beberapa formulir. Ditambah fakta bahwa HTML menghasilkan bentuk web sebagian besar waktu tidak terlalu SEO friendly (seperti dalam: sebagian besar kondisi tampilan di atas halaman)
jao

4
Saya harus setuju 100% dengan jawaban ini. Pada akhirnya, WebForms membuat melakukan hal-hal di sisi klien (html / browser) jauh lebih sulit. Anda benar-benar harus berjuang melawan kerangka kerja untuk menyelesaikan sesuatu. Halaman aspx berakhir dengan kode jauh lebih banyak karena kontrol server daripada halaman cshtml biasanya. @ šljaker Jika Anda mulai mematikan ViewState dan menghindari kontrol server, Anda telah meninggalkan banyak WebForms pada saat itu. Saya tidak melihat argumen itu sangat meyakinkan.
Andy

12
Anda dapat memiliki kontrol html biasa di WebForms, tidak ada yang memaksa Anda untuk menggunakan kontrol Server. Anda dapat memiliki Webform stateless lengkap, tidak ada yang memaksa Anda untuk menggunakan ViewState. Anda dapat menggunakan ajax penuh dan jQuery di Webforms, tidak ada yang membatasi Anda menggunakan jQuery. Anda dapat menerapkan perutean URL, tidak ada yang memaksa Anda untuk menggunakan URL basis file statis. Secara manual menggambar halaman dengan CSS menghabiskan waktu sebanyak yang dibutuhkan MVC. Anda dapat mendesain halaman HTML langsung di Webform.
mjb

5
@ mjb: Jika Anda tidak menggunakan kontrol server, kondisi tampilan dan sebagainya, mengapa menggunakan WebForms sama sekali ketika MVC lebih dekat dengan apa yang Anda lakukan? Ini seperti mengendarai traktor untuk bekerja tetapi tidak melakukan offroading atau menggunakan sekop / cangkul atau batang penstabil. Pada saat itu mengapa tidak menggunakan mobil saja?
Nelson Rothermel

3
@Tjaart Tidak sepenuhnya benar bahwa Anda tidak dapat memiliki beberapa formulir di halaman ASPNET. Anda dapat memiliki sebanyak mungkin formulir di halaman ASPNET tetapi Anda hanya dapat memiliki satu formulir - formulir server dengan atribut runat = "server".
Kuncevic

80

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.


12
Scott Guthrie menemukan kerangka kerja MVC untuk ASP.NET saat dalam penerbangan kembali dari London ke Seattle pada 2006/7. Kalau dipikir-pikir, dia cukup banyak menciptakan .NET juga ( en.wikipedia.org/wiki/Scott_Guthrie ). Menyebutnya seorang "ahli" adalah pernyataan yang luar biasa ;-)
Benjamin Howarth

27
Itu jawaban politik yang bagus dari Scott Guthrie. Jika dia sendiri yang menginvestasikan aplikasi webnya sendiri, Anda akan melihat proyek MVC dan untuk apa pun yang tidak dapat dilakukan di MVC, Silverlight akan menjadi mundur. Jangan menganggap ini sebagai komentar negatif terhadap WebForms, saya pikir WebForms bagus untuk aplikasi internal yang lebih kecil yang dapat mengambil manfaat dari komponen pihak ketiga seperti yang dibuat oleh Telerik. Saya senang Microsoft bergerak maju dengan kedua teknologi.
Sean Chase

10
"Scott Guthrie menemukan kerangka kerja MVC untuk ASP.NET saat dalam penerbangan" Saya pikir itu benar-benar meremehkan MVC. Saya tidak tahu Scott Guthrie, tapi saya berani bertaruh dia telah berspekulasi bagaimana MVC dapat diimplementasikan di ASP.NET untuk sementara waktu, dan menggunakan penerbangan panjang itu untuk mengimplementasikan prototipe tulang telanjang sebagai bukti konsep.
John MacIntyre

6
"Itulah sebabnya kami berinvestasi di keduanya." Dan ketika kita melihat bahwa formulir web mulai menurun, kita tanpa ampun akan menjatuhkannya karena berinvestasi pada produk yang akhirnya mati bukan untuk kepentingan bisnis terbaik kita.
Quandary

Sampai tidak lagi diajarkan di sekolah, selama bertahun-tahun, itu akan selalu berlaku di dunia bisnis. Perguruan tinggi dan sekolah menengah terus menawarkan kursus intro dan lanjutan di vb.net. Ini TIDAK kemana-mana !!!
htm11h

44

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.


Ini adalah jawaban yang baik, tetapi # 1 dan # 2 salah (WF tidak memerlukan komponen untuk mengetahui dari mana datanya berasal, itu adalah pilihan dan Anda selalu menambahkan HTML ke file ASPX Anda untuk mendukung tag asp Anda rendering. Anda tidak pernah perlu menggali lebih dalam dan melawan kontrol kecuali jika Anda mencoba mengakses fitur ASP yang tidak dimaksudkan untuk interaksi pengembang. Poin besar adalah
kemampuan uji coba

39

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. :)


+1 untuk gambar yang bagus disampaikan dengan "memainkan kedua sisi pagar dari file kode-balik yang bagus".
Marcel

Sangat membantu yang satu ini. Saya sedang melakukan aplikasi berbasis grid yang sangat berat dan saya sudah mengesampingkan silverlight, xbap dan itu turun ke show down antara keduanya.
frostymarvelous

15

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.


2
@ JimG - Uhh, apa pun yang melibatkan seseorang memasukkan catatan tanpa asosiasi yang menarik ke dalam basis data, dan membuat orang itu atau orang lain membaca / mencetaknya di beberapa titik lain pada dasarnya dapat dibuat menggunakan kerangka kerja MVC. Memang, itu bukan sebagian besar aplikasi, tapi itu lebih dari yang bisa Anda lakukan dengan Formulir. Saya kira -1 Anda membuktikan poin saya.
mootinator

1
Itu 1/4 hari.
mootinator

1
Tetapi jika persyaratannya adalah "Saya membutuhkan aplikasi dengan dua peran, satu untuk merekam beberapa informasi, yang lain untuk melihatnya, dan saya tidak terlalu peduli seperti apa tampilannya." Lalu, ya, itu cukup bisa dilakukan.
mootinator

3
Maaf, tetapi mengembangkan aplikasi formulir web untuk memasukkan data dan melihat data sangat sederhana, sehingga bisa dilakukan dalam beberapa jam. membuat struktur aplikasi MVC, Controllers, Views and Actions, akan membutuhkan waktu yang sama, tetapi tidak akan membawa Anda ke produk jadi.
Demensik

2
@Dementic Biasanya untuk aplikasi MVC sederhana yang membangun model, kemudian pengendali perancah dan tampilan dan / atau menghasilkan pengendali perancah / tampilan. Tidak ada yang benar-benar memakan waktu di sana.
mootinator

8

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.


7

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.


dapatkah Anda menjelaskan lebih detail mengapa Anda berpikir demikian?
nyamuk

saya pikir abstrak REST dasar sudah kembali, seluruh model postback kembali, cara html / css diserahkan dengan ketergantungan pada editor GUI buruk, penekanan pada hal-hal seperti penyihir dan GUI untuk mengatur semuanya buruk, URL buruk, dll dan seterusnya
scottschulthess

6

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.


6

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.


+1 Tentu saja argumen yang masuk akal untuk formulir Web. Ketakutan saya adalah bahwa tim mengikuti pola pikir ini untuk menghindari belajar hal-hal baru. MVC dipenuhi dengan banyak pola yang mungkin asing bagi tim. Mempelajari pola-pola ini dan menerapkannya mengarah pada kepatuhan yang lebih baik terhadap prinsip-prinsip SOLID yang diterjemahkan ke dalam pemeliharaan yang lebih baik secara keseluruhan. Teknik-teknik ini terbukti adalah juga kunci nyata untuk digunakan kembali.
P.Brian.Mackey

3

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.


1
Apakah Anda keberatan mendaftarkan beberapa fitur yang menurut Anda memerlukan Windows Server 2012?
MikeTeeVee

2

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,


2

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?


1

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.


Jadi KETIKA harus webforms disukai daripada MVC? Ini tidak menjawab pertanyaan poster aslinya.
Steven Striga

@WeekendWarrior - Ya, ketika Anda menginginkan lebih banyak akses sisi server ke klien, pilih formulir web. Jika Anda ingin lebih banyak decoupling dari klien / server dalam kode Anda, pilih MVC. Pada akhirnya, mereka berdua melakukan hal yang persis sama. Filter rute ulang melakukan hal yang sama dengan URL MVC dan Anda dapat memindahkan kode formulir web ke belakang ke tingkat menengah yang terpisah untuk memisahkannya. weblogs.asp.net/scottgu/archive/2010/01/24/…
Ryan Hayes

Mengenai poin ketiga Anda, logika bisnis itu berakhir di file .aspx.cs - Saya pikir ini adalah kesalahan pengembang. Itu tidak / seharusnya / ada di sana. Dalam Webforms, .aspx adalah "tampilan", .aspx.cs adalah setara "controller", yang dimaksudkan untuk memproses kode yang secara langsung berhubungan hanya dengan UI dengan polling lapisan bisnis atau lapisan fasad bisnis berbutir kasar. Fakta bahwa orang menaruh logika bisnis dalam .aspx.cs hanyalah pemrograman yang buruk. Mereka juga bisa menempatkan logika bisnis tepat di tampilan di MVC! MVC tidak memaksakan pemisahan hal-hal ini.
James

Pada dasarnya dia lebih benar daripada jawaban lain yang diposting di sini. ASP.net adalah ide dasar di balik keluarga teknologi web modular yang dibuat oleh Microsoft. Modul ASP.net MVC mungkin hype temporaly tetapi pasti itu bukan yang terakhir, semuanya dimulai dengan ASP.net, jadi ketika memilih ASP.net, jika Anda tidak berpikir bahwa MVC bukan hal Anda, mungkin Anda lebih menjadi sesuatu selain OWIN atau ..., sesuatu yang lebih maju, atau membuat kerangka kerja Anda sendiri untuk tugas-tugas Anda. Anda bahkan mungkin tidak perlu ASP.MVC dan lewati dan pergi Owin atau Katana, tetapi sampai Anda menggunakan asp.net
user3800527

1

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.


0

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.


Ditto pada kemampuan luas webforms. Kebanyakan orang melihat roda pelatihan bentuk web dan membandingkannya dengan MVC.
TheLegendaryCopyCoder

Ada sedikit akal dalam mempelajari abstraksi di atas HTML dan Javascript di zaman sekarang ini (bahkan di 2013). Ini tidak ada gunanya bagi peluang masa depan Anda. HTML dan Javascript tidak masalah. Melawannya adalah pertempuran yang kalah.
user441521

0

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.


0

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.


-1

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.


1
Bentuk web dan MVC merekomendasikan sikap pengembangan web yang sangat berbeda secara default, ini penting , beberapa pengembang menyimpang dari "default". Keduanya dapat digunakan untuk mencapai hal yang sama.
Raynos
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.