Kerangka Entitas VS LINQ ke SQL VS ADO.NET dengan prosedur tersimpan? [Tutup]

430

Bagaimana Anda menilai masing-masing dalam hal:

Performa
Kecepatan pengembangan
Kode rapi, intuitif, dapat dipelihara
Fleksibilitas
Secara keseluruhan

Saya suka SQL saya dan karena itu selalu menjadi penggemar berat dari ADO.NET dan prosedur tersimpan tetapi saya baru-baru ini bermain dengan Linq ke SQL dan terpesona oleh seberapa cepat saya menulis lapisan DataAccess saya dan telah memutuskan untuk menghabiskan beberapa waktu benar-benar memahami baik Linq to SQL atau EF ... atau tidak?

Saya hanya ingin memeriksa, bahwa tidak ada kesalahan besar dalam teknologi ini yang akan membuat waktu penelitian saya menjadi tidak berguna. Misalnya kinerjanya buruk, itu keren untuk aplikasi sederhana tetapi hanya bisa membawa Anda sejauh ini.

Pembaruan: Dapatkah Anda berkonsentrasi pada EF VS L2S VS SPs daripada ORM VS SPs. Saya terutama tertarik dengan EF VS L2S. Tetapi saya ingin memilikinya dibandingkan dengan procs yang disimpan juga karena SQl biasa adalah sesuatu yang saya tahu banyak tentang.

— Pengembang Inggris
sumber

94

tidak konstruktif dan belum begitu banyak upvotes? ...;)

— Pengembang Inggris

34

Saya tidak melihat mengapa seseorang menandai ini tidak konstruktif. Tampaknya sangat baik bagi saya. +1 dari saya.

— Thanushka

10

Ini adalah pertanyaan yang sangat bagus menurut saya. Secara pribadi, saya perhatikan Entity Framework dan semua ORM serupa di luar sana lebih lambat dibandingkan dengan kode ADO.Net yang sederhana / sederhana. Saya melakukan tes ini 2 tahun yang lalu dan sekali lagi seminggu yang lalu. Saya tidak yakin tentang bagaimana LINQ ke SQL dibandingkan dengan EF. Tetapi ADO.Net akan selalu menjadi yang terbaik dalam kinerja. Jika Anda ingin menghemat waktu dev, maka Entity Framework adalah alat yang baik tetapi jelas tidak ketika kinerja menjadi perhatian utama Anda.

— Sunil

2

@Timeless: Ada kecenderungan untuk tidak bergantung pada mekanisme basis data. Setiap mesin basis data memiliki bahasa prosedur tersimpannya sendiri, sehingga ada pembelajaran tambahan. 99,9% pengembang dapat mengandalkan ORM, yang menghasilkan kode yang cukup bagus dan membuat SQL secara otomatis. Perbedaan kinerja marjinal dalam kasus CRUD sederhana. Prosedur tersimpan lebih sulit untuk dikembangkan dan dipelihara. Beberapa tahun yang lalu, ketika tidak ada ORM dan tidak ada yang dihasilkan secara ajaib dan otomatis dari database. Menulis SP dianggap tidak terlalu memakan waktu, karena itu adalah alternatif untuk menulis pernyataan SQL dalam aplikasi.

— LukLed

4

@ Sunil benar, meskipun tidak cukup bertele-tele. Masalahnya adalah semua orang berpikir bahwa perhatian utama mereka adalah kinerja aplikasi. Ketika saya berbicara tentang aplikasi yang membutuhkan kinerja terbaik, saya berpikir tentang transaksi database C ++ MMO hardcore atau volume tinggi yang dihadapi pelanggan dalam jumlah besar. Anda benar-benar harus fokus pada prinsip-prinsip berorientasi objek seperti rawatan , keterbacaan , ketidaktahuan kegigihan dan pemisahan logika domain . Terutama ketika peningkatan kinerja adalah minor-at-best atau tidak ada dalam banyak kasus.

— Suamere

430

Pertama, jika Anda memulai proyek baru, gunakan Entity Framework ("EF") - sekarang menghasilkan SQL yang jauh lebih baik (lebih seperti Linq ke SQL) dan lebih mudah untuk mempertahankan dan lebih kuat daripada Linq ke SQL (" L2S "). Pada rilis. NET 4.0, saya menganggap Linq to SQL sebagai teknologi yang usang. MS sangat terbuka untuk tidak melanjutkan pengembangan L2S lebih lanjut.

1) Kinerja

Ini sulit dijawab. Untuk sebagian besar operasi entitas tunggal ( CRUD ), Anda akan menemukan kinerja yang setara dengan ketiga teknologi. Anda harus tahu cara kerja EF dan Linq to SQL untuk menggunakannya secara maksimal. Untuk operasi volume tinggi seperti kueri pemungutan suara, Anda mungkin ingin EF / L2S "mengkompilasi" kueri entitas Anda sedemikian rupa sehingga kerangka kerja tidak harus terus-menerus membuat ulang SQL, atau Anda dapat mengalami masalah skalabilitas. (lihat hasil edit)

Untuk pembaruan massal di mana Anda memperbarui data dalam jumlah besar, SQL mentah atau prosedur tersimpan akan selalu berkinerja lebih baik daripada solusi ORM karena Anda tidak harus menyusun data melalui kawat ke ORM untuk melakukan pembaruan.

2) Kecepatan Pengembangan

Dalam sebagian besar skenario, EF akan menerbangkan SQL / procs tersimpan telanjang ketika datang ke kecepatan pengembangan. Perancang EF dapat memperbarui model Anda dari basis data saat ia berubah (atas permintaan), sehingga Anda tidak mengalami masalah sinkronisasi antara kode objek dan kode basis data Anda. Satu-satunya waktu saya tidak akan mempertimbangkan menggunakan ORM adalah ketika Anda sedang melakukan aplikasi tipe pelaporan / dashboard di mana Anda tidak melakukan pembaruan, atau ketika Anda membuat aplikasi hanya untuk melakukan operasi pemeliharaan data mentah pada database.

3) Kode rapi / Maintainable

Hands down, EF mengalahkan SQL / sprocs. Karena hubungan Anda dimodelkan, bergabung dalam kode Anda relatif jarang. Hubungan entitas hampir jelas bagi pembaca untuk sebagian besar pertanyaan. Tidak ada yang lebih buruk daripada harus beralih dari tingkat ke tingkat debugging atau melalui beberapa SQL / tingkat menengah untuk memahami apa yang sebenarnya terjadi pada data Anda. EF membawa model data Anda ke dalam kode Anda dengan cara yang sangat kuat.

4) Fleksibilitas

Procs yang disimpan dan SQL mentah lebih "fleksibel". Anda dapat memanfaatkan sprocs dan SQL untuk menghasilkan kueri yang lebih cepat untuk kasus spesifik yang aneh, dan Anda dapat memanfaatkan fungsionalitas DB asli lebih mudah daripada dengan ORM.

5) Secara keseluruhan

Jangan terjebak dalam dikotomi keliru dalam memilih ORM vs menggunakan prosedur tersimpan. Anda dapat menggunakan keduanya dalam aplikasi yang sama, dan Anda mungkin harus melakukannya. Operasi massal besar harus menggunakan prosedur tersimpan atau SQL (yang sebenarnya bisa disebut oleh EF), dan EF harus digunakan untuk operasi CRUD Anda dan sebagian besar kebutuhan tingkat menengah Anda. Mungkin Anda akan memilih untuk menggunakan SQL untuk menulis laporan Anda. Saya kira moral ceritanya sama seperti sebelumnya. Gunakan alat yang tepat untuk pekerjaan itu. Tetapi kurusnya, EF sangat bagus saat ini (pada. NET 4.0). Habiskan waktu nyata membaca dan memahaminya secara mendalam dan Anda dapat membuat beberapa aplikasi luar biasa, berkinerja tinggi dengan mudah.

EDIT : EF 5 menyederhanakan bagian ini sedikit dengan Kueri LINQ yang dikompilasi otomatis , tetapi untuk hal-hal bervolume tinggi nyata, Anda pasti perlu menguji dan menganalisis apa yang paling cocok untuk Anda di dunia nyata.

— Dave Markle
sumber

35

Jawaban yang benar-benar brilian. Saya sekarang memang menggunakan EF untuk mengembangkan aplikasi dengan cepat. Jika kinerja menjadi masalah, procs yang disimpan akan dibawa ke refactor permintaan EF yang berkinerja buruk. Terima kasih!

— Pengembang Inggris

17

@BritishDeveloper: Juga, jangan lupa kekuatan menggunakan pandangan juga. Kami telah sukses besar dengan mendefinisikan beberapa pandangan dalam proyek-proyek L2S kami dan memanfaatkannya di mana kerangka kerja tampaknya untuk menulis pertanyaan yang buruk. Dengan begitu, kita mendapatkan semua manfaat menggunakan kerangka kerja dengan semua manfaat dari menulis SQL kita sendiri.

— Dave Markle

5

Saya juga menggunakan Views;) Lebih sebagai solusi untuk pembatasan EF non-silang. Ide bagus untuk digunakan untuk optimasi. Terima kasih

— Pengembang Inggris

5

Pasti respons yang bagus. Hanya ingin menambahkan pengamatan yang saya miliki dalam pengalaman saya sendiri dengan L2S vs EF4. Bertukar dari L2S -> EF4 setelah kami menyadari bahwa kami mungkin menggunakan beberapa RDMBS differnet ... tetapi, saat masih menjalankan MSSQL, penurunan kinerja terlihat terutama di area GUI aplikasi saya. Penyatuan data ke resultset di L2S jauh lebih cepat daripada EF4. Ini permintaan yang sama persis pada DB yang sama persis. Satu hal yang perlu diperhatikan di sini adalah saya mengembalikan 90k + catatan sehingga perbedaannya cukup jelas. Mungkin pada set yang lebih kecil itu tidak masalah? Tidak yakin bagaimana akan skala meskipun dengan situs vol tinggi ...

— bbqchickenrobot

5

Respon yang bagus Saya baru saja menghabiskan 4 minggu bekerja dengan LINQ-to-Entities, mencoba menyepelekan semuanya, sebelum akhirnya menyadari bahwa Anda memerlukan SQL asli untuk hal-hal seperti penyalinan massal, penghapusan massal, penghapusan duplikat yang sangat cepat dari database, dll. Gunakan alat yang tepat untuk pekerjaan itu, tidak ada rasa malu dalam berbaur SQL asli dengan kerangka kerja LINQ to Entities.

— Contango

93

Prosedur tersimpan:

(+)

Fleksibilitas yang luar biasa
Kontrol penuh atas SQL
Performa tertinggi yang tersedia

(-)

Membutuhkan pengetahuan tentang SQL
Prosedur yang tersimpan di luar kendali sumber
Jumlah substansial dari "mengulangi diri Anda" sambil menentukan tabel dan nama bidang yang sama. Peluang tinggi untuk menghancurkan aplikasi setelah mengganti nama entitas DB dan melewatkan beberapa referensi di suatu tempat.
Perkembangan lambat

ORM:

(+)

Perkembangan yang cepat
Kode akses data sekarang di bawah kendali sumber
Anda terisolasi dari perubahan DB. Jika itu terjadi, Anda hanya perlu memperbarui model / pemetaan Anda di satu tempat.

(-)

Kinerja mungkin lebih buruk
Tidak ada atau sedikit kontrol atas SQL yang dihasilkan ORM (bisa tidak efisien atau lebih buruk kereta). Mungkin perlu campur tangan dan menggantinya dengan prosedur tersimpan kustom. Itu akan membuat kode Anda berantakan (beberapa LINQ dalam kode, beberapa SQL dalam kode dan / atau dalam DB di luar kendali sumber).
Karena abstraksi apa pun dapat menghasilkan pengembang "tingkat tinggi" yang tidak tahu cara kerjanya di bawah tenda

Pengorbanan umumnya adalah antara memiliki fleksibilitas yang hebat dan kehilangan banyak waktu vs dibatasi dalam apa yang dapat Anda lakukan tetapi melakukannya dengan sangat cepat.

Tidak ada jawaban umum untuk pertanyaan ini. Ini masalah perang suci. Juga tergantung pada proyek yang Anda hadapi dan kebutuhan Anda. Ambil yang terbaik untuk Anda.

— AGuyCalledGerald
sumber

47

Saya tidak berpikir poin tentang kontrol sumber relevan. Skema basis data, prosedur tersimpan, UDF, dll semuanya bisa, dan harus di bawah kendali sumber.

— Lee Gunn

15

+1 untukAs any abstraction can produce "high-level" developers having no idea how it works under the hood

— nawfal

3

Setuju, argumen kontrol sumber salah. Kami selalu menyimpan skrip pembuatan basis data kami di svn. Bagaimana Anda bisa menjaga database di luar kendali sumber ketika mengembangkan aplikasi database?

— Wout

3

EF tidak benar-benar cocok untuk ketersediaan tinggi dan kinerja tinggi, saya bukan orang DBA tapi saya tidak melihat apa yang menawarkan EF yang membuatnya lebih mudah untuk dikodekan.

— Jamie

4

Jadi, kami memberikan fleksibilitas, kontrol penuh, dan kinerja untuk "pengembangan cepat" dan menghindari perubahan kode jika DB berubah. Kedengarannya seperti kemalasan bagiku.

— user2966445

18

pertanyaan Anda pada dasarnya adalah O / RM vs tulisan tangan SQL

Menggunakan ORM atau SQL biasa?

Lihatlah beberapa solusi O / RM lain di luar sana, L2S bukan satu-satunya (NHibernate, ActiveRecord)

http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software

untuk menjawab pertanyaan spesifik:

Bergantung pada kualitas solusi O / RM, L2S cukup bagus dalam menghasilkan SQL
Ini biasanya jauh lebih cepat menggunakan O / RM setelah Anda melakukan proses
Kode juga biasanya lebih rapi dan lebih dapat dipelihara
Straight SQL tentu saja akan memberi Anda lebih banyak fleksibilitas, tetapi sebagian besar O / RM dapat melakukan semua kecuali pertanyaan yang paling rumit
Secara keseluruhan saya akan menyarankan pergi dengan O / RM, kehilangan fleksibilitas diabaikan

— Es hitam
sumber

@ David Terima kasih, tetapi bukan ORM vs SQL. Saya mencari untuk pindah ke ORM dan saya bertanya-tanya mana yang akan menginvestasikan waktu dalam belajar: EF atau L2S (kecuali mereka sampah dibandingkan dengan Stored Procs)

— BritishDeveloper

1

Saya pasti akan mengatakan itu bukan sampah dibandingkan dengan procs yang disimpan, dan keuntungan sampingannya adalah Anda tidak memiliki kode yang menyebar ke database. Secara pribadi saya suka L2S, tetapi saya belum melakukan banyak hal dengan EF saat ini, dan tampaknya L2EF akan menggantikannya, jadi saya akan pergi EF. Juga, begitu Anda pergi Linq, Anda tidak kembali.

— BlackICE

13

LINQ-to-SQL adalah teknologi luar biasa yang sangat mudah digunakan, dan pada umumnya menghasilkan pertanyaan yang sangat bagus ke bagian belakang. LINQ-to-EF dijadwalkan menggantikannya, tetapi secara historis sangat kikuk untuk menggunakan dan menghasilkan SQL yang jauh lebih rendah. Saya tidak tahu keadaan saat ini, tetapi Microsoft berjanji untuk memigrasi semua kebaikan L2S ke L2EF, jadi mungkin sekarang semuanya lebih baik.

Secara pribadi, saya sangat tidak menyukai alat ORM (lihat cacian saya di sini untuk detailnya), jadi saya tidak melihat alasan untuk menyukai L2EF, karena L2S memberi saya semua yang saya harapkan dari lapisan akses data. Bahkan, saya bahkan berpikir bahwa fitur L2S seperti pemetaan kerajinan tangan dan pemodelan pewarisan menambahkan kompleksitas yang sama sekali tidak perlu. Tapi itu hanya aku. ;-)

— Marcelo Cantos
sumber

1

L2S cukup bagus, tetapi memiliki kelemahan yang Microsoft telah nyatakan bahwa mereka pada dasarnya tidak akan berinvestasi banyak dalam mengembangkannya. Anda dapat melihat hasil ini sudah dalam versi terbaru yang hanya memiliki beberapa perbaikan bug dan beberapa dukungan untuk tipe data SQL Server 2008 ditambahkan.

— FinnNk

Setuju, @FinnNk. Ini adalah kenyataan yang disayangkan bahwa menggunakan L2S agak berisiko karena statusnya paria. Tetapi jika mereka benar-benar melakukannya dengan sepenuhnya mendukung L2EF, saya sangat curiga akan ada jalur migrasi, karena berikut ini masih dinikmati.

— Marcelo Cantos

3

Linq ke EF telah matang, dan sekarang menghasilkan SQL sebaik L2S (pada. NET 4.0). L2EF jauh lebih baik daripada L2S saat ini, karena setidaknya dapat memperbarui model Anda sebagai perubahan DB, yang L2S tidak pernah bisa lakukan secara otomatis. Saya juga menyukai kenyataan bahwa Anda dapat memetakan hubungan M: M sederhana dengan EF sebagai hubungan tanpa harus memiliki entitas perantara. Itu membuat kode yang jauh lebih bersih.

— Dave Markle

2

Terima kasih atas pembaruan @Dave. Namun saya tidak setuju dengan komentar M: M. Skema yang saya kerjakan dengan hampir selalu menumbuhkan atribut tambahan di tabel bergabung. Ini menginduksi perubahan struktural ke model objek, membutuhkan banyak pengerjaan ulang kode. Saya lebih suka berurusan dengan hubungan antara secara eksplisit sejak awal.

— Marcelo Cantos

1

Ada pendekatan yang sama sekali baru yang mungkin ingin Anda pertimbangkan jika yang Anda kejar adalah kekuatan dan kinerja prosedur tersimpan, dan perkembangan cepat yang disediakan alat-alat seperti Kerangka Entitas.

Saya telah mengambil SQL + untuk test drive pada proyek kecil, dan itu benar-benar sesuatu yang istimewa. Anda pada dasarnya menambahkan jumlah komentar pada rutinitas SQL Anda, dan komentar itu memberikan instruksi kepada pembuat kode, yang kemudian membangun pustaka kelas berorientasi objek yang sangat bagus berdasarkan pada rutin SQL aktual. Jenis kerangka entitas suka secara terbalik.

Parameter input menjadi bagian dari objek input, parameter output dan set hasil menjadi bagian dari objek output, dan komponen layanan menyediakan panggilan metode.

Jika Anda ingin menggunakan prosedur tersimpan, tetapi masih menginginkan perkembangan yang cepat, Anda mungkin ingin melihat hal-hal ini.

— Vincent
sumber