Aspnetcore: MVC terlalu rumit untuk digunakan?

Jika Anda bukan penggemar ORM (Object Relation Mappers) seperti EntityFramework, Anda dapat menulis SQL secara manual menggunakan ADO.NET. Anda juga dapat menggunakan ORM ringan seperti Dapper yang tidak menghasilkan kueri (Anda dapat menulisnya dengan tangan). EntityFramework juga memiliki metode ExecuteSQL untuk memberi Anda kontrol lebih saat diperlukan (https://docs.microsoft.com/en-us/ef/core/querying/raw-sql).

Juga, jika MVC terlihat terlalu rumit untuk halaman sederhana, cobalah Razor Pages

Saya sangat menyarankan Anda mengikuti salah satu dari banyak tutorial MVC; seseorang tidak dapat berharap untuk memahami sesuatu seolah-olah dengan sihir hanya dari 5 menit melihat template proyek baru.

Adapun kesederhanaan relatif terhadap formulir web, bolehkah saya mengingatkan Anda tentang kemalangan kondisi tampilan, runat=server dan tuhan menyelamatkan kita semua dari siklus hidup halaman.
Salam Hormat

Ini lucu.

Tampaknya cukup mudah bagi saya.

Juga, jika MVC terlihat terlalu rumit untuk halaman sederhana, cobalah Razor Pages

Baru saja menyelesaikan WebForms -> proyek migrasi RazorPages - Sejujurnya bisa saja MVC biasa tetapi jelas merupakan pilihan yang baik untuk situs web 'halaman-sentris' kecil. Dalam proyek MVC saya merasa saya terlalu banyak 'berburu' kode, mis. melompat dari View ke Controller terus-menerus, menggulir melalui rim Actions sedangkan di RazorPages saya hanya akan langsung ke PageModels.

Saya benci EF kembung - Dapper jauh lebih sederhana, terutama jika digunakan dengan sesuatu seperti Dapper.FastCRUD

Bukan hanya Anda @LJ9999 , MVC dan kerangka kerja apa pun tidak memiliki semua jawaban. Ini mungkin bukan struktur terbaik yang cocok untuk proyek Anda, dan mungkin tidak sesuai dengan cara berpikir Anda. Tidak perlu mencoba memasukkan pasak persegi ke dalam lubang bundar kecuali Anda suka menghukum diri sendiri.

MVC adalah salah satu pilihan Anda. Evaluasi beberapa pendekatan berbeda, dan pilih salah satu yang paling cocok untuk Anda. Temukan sesuatu yang masuk akal bagi Anda. Temukan (atau buat) sesuatu di mana Anda paling produktif. Jangan terpengaruh oleh apa yang populer. Populer tidak selalu tentang prestasi, dan bahkan apa yang pantas untuk satu kasus tidak bekerja di tempat lain.

Jadi izinkan saya bergabung dengan Anda untuk bersikap skeptis tentang cara paling umum untuk menyelesaikan sesuatu. Menjadi skeptis tentang pendekatan yang diambil semua orang, dan berpikir kritis dan untuk diri sendiri adalah tempat yang baik untuk memulai. Jika Anda berpikir Anda bisa melakukan lebih baik, Anda mungkin bisa. Pergi untuk itu!

Bagi siapa pun yang membaca yang merasa ini sebagai serangan terhadap mereka dan cara populer yang mereka pilih, itu benar-benar bukan serangan terhadap Anda. Dikatakan temukan apa yang cocok untuk Anda. Jadi itu hanya pernyataan tentang bagaimana, sementara komputer semua mungkin berjalan pada bahasa yang sama, pikiran orang tidak. Setiap orang berbeda, dan itu bagus.

+1 untuk necis, gunakan itu.

Mengenai mengapa Anda menggunakan kerangka kerja entitas, ini adalah cara cepat dan mudah untuk mengekspresikan perilaku yang Anda inginkan dalam bahasa yang sama dengan yang Anda gunakan untuk mendefinisikan kode Anda, dengan kode gen supoort (baca: pengurangan waktu ke pasar). Saya biasanya tidak menggunakannya, dan Anda juga tidak harus menggunakannya.

Sepertinya Anda mungkin lebih mempermasalahkan penggunaannya dalam sebuah contoh. Jawabannya adalah audiens target: lebih banyak orang yang berpengalaman dalam paradigma ORM pada tahun 2019 daripada yang benar-benar terampil dalam SQL. SQL tidak mati, hanya memiliki banyak persaingan yang kuat dengan penetrasi yang tinggi di kontingen pengembang yang lebih muda.

Sebagai seseorang yang telah melalui setiap iterasi Asp.Net, dan MVC hingga apa yang kita miliki sekarang dengan Asp.Net Core, saya dapat memberi tahu Anda bahwa men-debug bug siklus hidup halaman dan mencoba membuat sesuatu dengan kompleksitas relatif apa pun dengan formulir web adalah mimpi buruk dibandingkan ke MVC. WebForms menyembunyikan banyak pekerjaan sebenarnya yang terjadi di balik apa yang tampak seperti peristiwa ajaib. Ini mengabstraksi seluruh cara permintaan web bekerja dengan mencoba memegang tangan Anda dan berpura-pura bahwa web tidak tanpa kewarganegaraan. Itu berbohong kepada Anda dan memberi tahu Anda bahwa Anda cantik dan pantat Anda terlihat bagus dengan jeans itu. Ini salah membangun kepercayaan diri Anda dan membuat teknologi web menjadi kabur. Dan Anda dengan senang hati menjalani hari Anda dengan berpikir bahwa jika Anda dapat membuat halaman web dengan formulir di atasnya dan menyimpannya ke dalam tabel, maka Anda dapat melakukan apa saja. Sampai Anda mendapatkan persyaratan baru untuk membuat formulir dinamis khusus. Atau buat sesuatu bekerja dengan kerangka sisi klien khusus ini, karena klien menganggapnya cantik. Anda menyadari bahwa Anda sekarang bekerja melawan arus dan bertanya-tanya bagaimana orang lain melakukannya.
MVC bukanlah ilmu roket, ini adalah pola yang telah terbukti yang telah berkembang dalam komunitas pembangunan setelah menyadari "harus ada cara yang lebih baik" dan bertahun-tahun menancapkan pasak bulat di lubang persegi. Jika menurut Anda itu rumit, itu mungkin karena Anda belum menemukan masalah yang seharusnya diperbaiki dan Anda tidak menghabiskan cukup waktu untuk memecahkan masalah yang rumit. Mulailah dengan tutorial yang lebih sederhana jika yang satu ini sangat banyak.
Jika Anda memutuskan ini bukan untuk Anda, selalu ada PHP atau NodeJs.

Untuk sesuatu yang lebih dari sekadar gabungan sepele, saya hanya akan menggunakan EF's ExecuteSQL. Saya pikir Anda mungkin meremehkan kompleksitas yang mungkin coba diwakilinya karena tidak memiliki cara untuk memberi nama tabel gabungan secara logis dan mungkin perlu fleksibel dengan tugas kantor. Jika Anda tidak menyukai EF, Anda tidak sendirian. Kebanyakan orang yang menggunakan MVC mungkin tidak menggunakan EF. Yang satu tidak membutuhkan yang lain.

Secara pribadi saya menemukan formulir web jauh lebih rumit daripada MVC karena mereka memiliki begitu banyak logika peristiwa kompleks yang mengaburkan apa yang sebenarnya merupakan siklus respons permintaan. MVC untuk seseorang yang tidak pernah memikirkannya pada awalnya sulit karena merupakan model organisasi yang berbeda, tetapi setelah bertahun-tahun digunakan, industri tampaknya telah memutuskan bahwa MVC sebenarnya lebih sederhana dalam jangka panjang. Ini hanya masalah preferensi, tetapi membuka tiket seperti ini pada teknologi yang telah menjadi arus utama selama bertahun-tahun hanyalah ventilasi.

Saya merekomendasikan mempelajari MVC dengan contoh yang tidak menggunakan kerangka kerja entitas sehingga Anda mempelajari satu konsep sekaligus. Namun, ini bukan tempat yang tepat untuk membicarakannya.

OMG aku tertawa sangat keras sekarang.

Dengar sobat, jika tampaknya terlalu sulit atau rumit maka menjauhlah darinya dan gunakan sesuatu yang lain. Tidak ada yang menodongkan pistol ke kepala Anda, bukan?

Beberapa dari kita telah berada di sekitar blok beberapa kali dan lebih memilih kesederhanaan asp mvc daripada formulir web karena kita harus berurusan dengan tumpukan kode spaghetti yang tidak dapat diuji yang keluar dari monstrositas bentuk web monolitik.

Tapi serius, jika Anda menyukai formulir web, dan seseorang bersedia membayar Anda untuk membuat kode formulir web, lakukanlah! Dan berhenti merengek tentang hal-hal yang tidak Anda mengerti.

Apakah ini postingan satir? Tidak yakin apakah di reddit atau github ...

Saya telah bekerja pada pengembangan ERP di bawah formulir web Asp.net, dan Asp.net MVC untuk dua sistem yang berbeda, saya yakin dapat mengatakan bahwa bekerja pada formulir web adalah siksaan terutama ketika Anda memiliki solusi besar dengan arsitektur yang buruk, dan sebaliknya MVC secara ajaib dapat mengubah arsitektur yang tampak jelek menjadi solusi tingkat atas dengan kemampuan untuk mengatur lapisan dan memanfaatkan pola repositori dengan ORM andal yang kuat seperti EF.
tapi sejujurnya sebagian besar pengembang yang saya temui yang mengeluh tentang MVC menderita karena pengalaman dan pengetahuan yang terbatas tentang pola baru.
Saya pribadi menyarankan pengembang yang ingin mempelajari MVC dari nol hingga pahlawan untuk mencoba https://www.pluralsight.com daripada berkeliling web dan membuang waktu dan uang untuk topik dan blog kontroversial di MVC yang dalam banyak kasus bias atau buruk dalam konteks.

Wow, waktu itu ada perubahan pengembang yang sebenarnya benar. Saya memuji Microsoft pada betapa mudah dan lurusnya EF dan MVC ketika saya pertama kali menemukannya pada tahun 2013. Seperti yang sudah dikatakan, memahami kerangka kerja ini tidak terjadi secara otomatis! Ikuti tutorialnya, tonton beberapa dari ratusan video di luar sana dan coba lagi. Maaf, tetapi Anda mengembangkan pemahaman tentang hal-hal ini saat Anda menghabiskan waktu dengannya

Saya setuju dengan penulis. Bagi orang-orang yang menggunakan mvc untuk pertama kalinya. Pendekatannya tidak seramah yang lain seperti php, rail.. terlalu banyak konsep yang harus dipahami sebelum menggunakannya. Namun, begitu Anda mendapatkan konsepnya, mvc tampaknya sangat efektif.

Mengapa ada orang yang membenci kerangka entitas. Saya harus menulis tidak lebih dari 5 kueri SQL dalam tiga tahun terakhir.

Meskipun ini bukan ilmu roket, pada akhirnya ada beberapa ilmu di baliknya dan seperti semuanya, mungkin perlu beberapa waktu dan usaha untuk sepenuhnya memahami, saya dengan penulis asli, bahwa MVC dan sampelnya sedikit luar biasa ketika mencoba memahami semuanya dalam sekali duduk, mungkin jika ada semacam lembar contekan untuk digunakan saat menerapkan pengetahuan atau konsep dari kerangka kerja lain dapat membuat pembelajaran MVC lebih tertahankan bagi mereka yang merasa menantang.

Sementara umpan balik selalu dihargai, karena jika seseorang mengeluh, itu berarti ada sesuatu untuk diperbaiki, di sisi lain jika Anda melakukan sedikit investigasi pada posting penulis, Anda akan menemukan bahwa dia sangat vokal dan membandingkan banyak hal dengan ilmu roket.

Beberapa sampel:
https://github.com/dotnet/docs/issues/9115
https://github.com/dotnet/docs/issues/9299
https://github.com/dotnet/docs/issues/9274
https://github.com/dotnet/docs/issues/9234
https://github.com/MicrosoftDocs/azure-docs/issues/20313
https://github.com/dotnet/docs/issues/9396
https://github.com/aspnet/EntityFramework6/issues/671
https://github.com/aspnet/EntityFramework6/issues/686
https://github.com/twbs/bootstrap/issues/27783
https://github.com/MicrosoftDocs/visualstudio-docs/issues/2237
https://github.com/aspnet/EntityFramework.Docs/issues/1254
https://github.com/aspnet/EntityFramework.Docs/issues/1240

Bahkan ketika hal-hal bukan ilmu roket mereka masih bisa rumit dan membutuhkan kesabaran untuk belajar. Membaca lebih banyak tentang topik daripada mengeluh terlalu sulit mungkin merupakan tempat yang baik untuk memulai.

Tampaknya masalah Anda bukan dengan MVC, tetapi Entity Framework. Bagi sebagian dari kita yang nyaman menulis SQL, Entity Framework menambahkan lapisan abstraksi yang tidak diinginkan. Secara pribadi, saya menggunakan Dapper, yang membuat penggunaan Pembaca menjadi lebih mudah. Anda masih bisa menulis SQL Anda sendiri. MVC adalah pola yang cukup sederhana. Ini menjadi sedikit lebih rumit untuk memahami cara meneruskan data masuk dan keluar dan bagaimana menggunakan beberapa fungsi pembantu secara efektif, tetapi secara konseptual itu tidak sulit.

MVC tidak memerlukan penggunaan EF, meskipun otentikasi pengguna bawaan menggunakannya.

Teman, beri komentar dengan bantuan atau hal positif, tetapi jangan dengan ejekan. OP tampaknya memiliki masalah dengan EF, dan komentar David sangat bagus. https://github.com/aspnet/AspNetCore/issues/7039#issuecomment -457869924

Masalah adalah tempat untuk membantu. Jika Anda ingin memperdebatkan keunggulan MVC vs sesuatu yang lain, cobalah salah satu situs keluhan populer di Internet.

Hai, selamat datang @LJ9999 Saya berharap lebih banyak orang akan mengajukan pertanyaan seperti ini.
Saya akan mulai dengan mengatakan ini hanyalah pendapat saya, jadi silakan setuju atau tidak setuju dengan salah satu atau semuanya.

Saya sangat setuju bahwa pengembangan web/perangkat lunak itu sulit. Saya pribadi telah menghabiskan bertahun-tahun belajar dan bereksperimen untuk mendapatkan pengalaman yang saya miliki. Setiap kali saya ingin menggunakan kerangka kerja atau perpustakaan baru masih sulit. Itu mengharuskan saya untuk menghabiskan lebih banyak waktu untuk belajar dan bereksperimen lagi agar nyaman dan percaya diri menggunakannya. Karena saya telah belajar semakin banyak selama bertahun-tahun, saya benar-benar percaya bahwa saya telah menjadi lebih baik dan lebih cepat dalam belajar sehingga menjadi lebih mudah.
Selama bertahun-tahun, saya pikir tantangan yang terlibat telah berubah. Beberapa hal menjadi lebih mudah namun tantangan baru juga telah diperkenalkan. Namun secara keseluruhan, saya percaya ini jauh lebih mudah sekarang dibandingkan ketika saya mulai. Saya juga berpikir ini bukan pengalaman yang membuat frustrasi dan saya merasa itu lebih menyenangkan.
Setelah mengatakan semua itu, saya pikir sebagai sebuah industri kita selalu dapat terus berusaha untuk menjadi lebih baik. Saya pikir pertanyaan seperti ini yang menyoroti tantangan yang kita hadapi dan menginspirasi kebutuhan untuk terus memperbaiki situasi.

Saya ingin sangat berhati-hati untuk tidak menyarankan Anda memilih satu solusi di atas yang lain karena saya tidak percaya ada cukup informasi bagi saya untuk melakukannya.
Salah satu tantangan terbesar yang saya temukan dengan pemecahan masalah adalah mengidentifikasi masalah yang sebenarnya sedang dipecahkan. Akan sangat mudah untuk mengkategorikan masalah ini sebagai kebutuhan untuk "membangun situs web" namun dengan begitu banyak solusi yang dapat dipilih untuk "membangun situs web", salah satu dari solusi tersebut berpotensi berfungsi. Masalahnya perlu dipecah sebanyak mungkin karena ini memberikan kriteria untuk mengevaluasi solusi yang berbeda.
Kedua, kita semua memiliki preferensi pribadi. Anda berhak atas milik Anda sendiri, dan tidak ada yang bisa memberi tahu Anda apa yang Anda sukai atau merasa lebih nyaman bekerja dengannya. Ini sepenuhnya berdasarkan Anda.
Juga, ketika orang lain terlibat, sebuah tim atau perusahaan, faktor tambahan mungkin perlu dipertimbangkan seperti preferensi tim, serta kebijakan dan strategi perusahaan.
Ini hanyalah beberapa faktor yang terlibat yang perlu dipertimbangkan ketika mengevaluasi solusi yang berbeda.

Satu hal terakhir yang ingin saya sampaikan adalah pesan Anda. Saya pikir itu tidak cukup spesifik untuk memahami apa yang Anda harapkan dari sebuah tanggapan. Dalam interpretasi saya, ada banyak pertanyaan berbeda yang Anda coba dapatkan jawabannya, serta Anda memberikan pendapat Anda. Ini semua valid dan berguna namun ketika ditanya dan diangkat bersama dalam satu masalah github, sulit untuk mengumpulkan jawaban yang jelas dan ringkas atau memulai diskusi untuk memberi Anda jawaban yang Anda cari.
Saran saya kepada Anda adalah mencoba lagi dan lebih spesifik dengan pertanyaan atau pendapat Anda. Jangan khawatir tentang membuka banyak masalah, jika mereka ditulis dengan baik dan cakupannya akan jauh lebih baik diterima dan Anda jauh lebih mungkin untuk mendapatkan jawaban atas pertanyaan Anda atau diarahkan dengan tepat.

Saya harap tanggapan ini membantu dalam beberapa hal. Ketahuilah bahwa ada banyak orang yang bersedia membantu, tetapi Anda bertanggung jawab untuk memudahkan seseorang membantu Anda.

@LJ9999 satu (semoga membangun) komentar...

Dari SQL yang Anda posting, kemungkinan Anda menggunakan Entity Framework 6. Entity Framework Core (versi yang lebih baru yang ditulis dari bawah ke atas) memiliki tujuan eksplisit untuk menghasilkan SQL yang waras dan dapat dibaca yang mencoba menyerupai apa yang Anda tulis sendiri - ada kemungkinan besar jika Anda mencobanya, Anda akan melihat sesuatu yang lebih masuk akal - cobalah dan beri tahu kami.

Kriteria garis bawah saya sederhana... Jumlah baris kode yang harus diterapkan. Lebih banyak kode - lebih banyak risiko bug, kurva pembelajaran yang lebih besar, lebih banyak jam terbuang (kecuali jika Anda adalah kontraktor yang menagih per jam).
Saya telah melihat volume kode 8x lebih besar dari melakukan mvc dengan kerangka kerja Javascript.. Lebih dari halaman cshtml sekolah lama. Dan 5x lebih banyak waktu.

Waspadalah terhadap mereka yang menggunakan frasa "jalan yang benar"

MVC sebagai arsitektur perangkat lunak lebih membantu Anda dalam hal ini.
M adalah modelnya, yang bisa menjadi basis data Anda, ia dapat menanggapi permintaan informasi, menanggapi instruksi untuk mengubah status informasinya, dan bahkan memberi tahu pengamat dalam sistem yang digerakkan oleh peristiwa ketika informasi berubah.
V adalah tampilan, yang secara efektif menyediakan elemen antarmuka pengguna aplikasi. Ini akan membuat data dari model menjadi bentuk yang cocok untuk antarmuka pengguna.
C adalah pengontrol, yang menerima input pengguna dan membuat panggilan ke objek model atau hanya membuat tampilan.

Pilihan tumpukan teknologi Anda tidak berarti MVC baik atau buruk, itu hanya arsitektur perangkat lunak.

@shanselman

Teman, beri komentar dengan bantuan atau hal positif, tetapi jangan dengan ejekan. OP tampaknya memiliki masalah dengan EF, dan komentar David sangat bagus. #7039 (komentar)

Saya sepenuhnya setuju Scott.

Dapat juga dimengerti bahwa beberapa pengguna yang lebih berpengalaman merasa kuat tentang judul yang tampaknya menghapus kerangka kerja hebat dan kerja keras bertahun-tahun oleh tim inti ASP.NET dan komunitas sebagai 'tidak dapat digunakan' dalam satu pernyataan meskipun itu mungkin bukan niatnya. Saya pikir itu mungkin menyebabkan ejekan.

Mungkin membantu untuk mengubah judul agar sesuai dengan masalah yang sebenarnya.

Kami secara berkala menutup masalah 'diskusi' yang belum diperbarui dalam jangka waktu yang lama.

Kami mohon maaf jika hal ini menyebabkan ketidaknyamanan. Kami meminta jika Anda masih mengalami masalah, harap catat masalah baru dengan informasi terbaru dan kami akan menyelidikinya.