LINQ-to-SQL vs prosedur tersimpan? [Tutup]


188

Saya melihat tulisan "Panduan Pemula untuk LINQ" di StackOverflow ( Panduan Pemula untuk LINQ ), tetapi memiliki pertanyaan lanjutan:

Kami akan meningkatkan proyek baru di mana hampir semua operasi basis data kami akan menjadi pengambilan data yang cukup sederhana (ada segmen lain dari proyek yang sudah menulis data). Sebagian besar proyek kami yang lain sampai saat ini menggunakan prosedur tersimpan untuk hal-hal seperti itu. Namun, saya ingin memanfaatkan LINQ-to-SQL jika lebih masuk akal.

Jadi, pertanyaannya adalah ini: Untuk pengambilan data sederhana, pendekatan mana yang lebih baik, LINQ-to-SQL atau procs yang disimpan? Adakah pro atau kontra tertentu?

Terima kasih.

Jawaban:


192

Beberapa keuntungan dari LINQ dibandingkan sprocs:

  1. Jenis keamanan : Saya pikir kita semua mengerti ini.
  2. Abstraksi : Ini terutama berlaku untuk LINQ-to-Entities . Abstraksi ini juga memungkinkan kerangka kerja untuk menambahkan perbaikan tambahan yang dapat Anda manfaatkan dengan mudah. PLINQ adalah contoh menambahkan dukungan multi-threading ke LINQ. Perubahan kode minimal untuk menambahkan dukungan ini. Akan jauh lebih sulit untuk melakukan kode akses data ini yang hanya memanggil sprocs.
  3. Dukungan debugging : Saya bisa menggunakan .NET debugger untuk men-debug kueri. Dengan sprocs, Anda tidak dapat dengan mudah men-debug SQL dan pengalaman itu sebagian besar terkait dengan vendor database Anda (MS SQL Server menyediakan penganalisis kueri, tetapi seringkali itu tidak cukup).
  4. Agnostik vendor : LINQ bekerja dengan banyak basis data dan jumlah basis data yang didukung hanya akan meningkat. Sprocs tidak selalu portabel di antara basis data, baik karena beragam sintaks atau dukungan fitur (jika basis data mendukung sprocs sama sekali).
  5. Penempatan : Yang lain sudah menyebutkan ini, tetapi lebih mudah untuk menggunakan satu perakitan daripada menggunakan satu set sprocs. Ini juga terkait dengan # 4.
  6. Lebih mudah : Anda tidak harus belajar T-SQL untuk melakukan akses data, Anda juga tidak harus belajar API akses data (misalnya ADO.NET) yang diperlukan untuk memanggil sprocs. Ini terkait dengan # 3 dan # 4.

Beberapa kelemahan dari LINQ vs sprocs:

  1. Lalu lintas jaringan : sprocs hanya membutuhkan cerita bersambung nama-spro dan data argumen melalui kawat sementara LINQ mengirimkan seluruh kueri. Ini bisa menjadi sangat buruk jika pertanyaannya sangat kompleks. Namun, abstraksi LINQ memungkinkan Microsoft untuk meningkatkan ini dari waktu ke waktu.
  2. Kurang fleksibel : Sprocs dapat memanfaatkan penuh set fitur database. LINQ cenderung lebih umum dalam mendukungnya. Ini biasa terjadi dalam segala jenis abstraksi bahasa (mis. C # vs. assembler).
  3. Kompilasi ulang : Jika Anda perlu melakukan perubahan pada cara Anda melakukan akses data, Anda perlu mengkompilasi ulang, versi, dan memindahkan kembali perakitan Anda. Sprocs terkadang dapat memungkinkan DBA untuk menyempurnakan rutinitas akses data tanpa perlu memindahkan apa pun.

Keamanan dan pengelolaan adalah sesuatu yang orang juga perdebatkan.

  1. Keamanan : Misalnya, Anda dapat melindungi data sensitif Anda dengan membatasi akses ke tabel secara langsung, dan meletakkan ACL pada sprocs. Dengan LINQ, namun Anda masih dapat membatasi akses langsung ke meja dan bukan menempatkan ACL di atas meja diupdate pandangan untuk mencapai akhir yang sama (dengan asumsi Anda mendukung database yang diupdate dilihat).
  2. Kelola : Menggunakan tampilan juga memberi Anda keuntungan melindungi aplikasi Anda tanpa terputus dari perubahan skema (seperti normalisasi tabel). Anda dapat memperbarui tampilan tanpa memerlukan kode akses data Anda untuk berubah.

Saya dulunya adalah orang besar, tetapi saya mulai condong ke arah LINQ sebagai alternatif yang lebih baik secara umum. Jika ada beberapa area di mana sprocs jelas lebih baik, maka saya mungkin masih akan menulis sproc tetapi mengaksesnya menggunakan LINQ. :)


33
"LINQ bekerja dengan banyak basis data" Tetapi LINQTOSQL hanya mendukung SQL Server.
RussellH

7
LINQ to Entities bekerja dengan Postgres dan MySql di samping MSSQL. Tidak yakin, tapi saya pikir saya membaca ada sesuatu untuk Oracle di sekitar.
bbqchickenrobot

devCart dotConnect memiliki hal Oracle, tapi itu buggy sekali. Juga, saya tidak bisa mengatasi defisit kinerja yang diperkenalkan dengan harus memilih data dari database untuk memperbaruinya (Lampirkan () juga mungkin, tapi agak mudah)
Ed James

5
Saya belum melihat seorang pun di sini menyebutkan penggunaan kembali kode. Anda tidak dapat menggunakan kembali linq di aplikasi pro VB6 atau asp atau pembuat file. Jika Anda memasukkan sesuatu ke dalam basis data maka dapat digunakan kembali di MANA SAJA. Anda bisa membuat dll dengan LINQ di dalamnya saya kira tapi itu semakin rumit dan imo jelek. Menambahkan fungsi atau proc tersimpan yang dapat digunakan kembali jauh lebih sederhana.
MikeKulls

Berbicara tentang Kode Digunakan kembali dalam TSQL (1) semoga berhasil mencoba menyimpan hasil dari prosedur yang tersimpan ke dalam tabel temp tanpa menggunakan sql dinamis. (2) Tidak banyak yang dapat Anda lakukan untuk mengatur semua procs / fungsi Anda; namespace menjadi berantakan dengan cepat. (3) Anda telah menulis pernyataan pilih yang kuat tetapi sekarang Anda ingin pengguna dapat memilih kolom yang diurutkan - dalam TSQL Anda mungkin harus menggunakan CTE yang melakukan jumlah baris pada setiap kolom yang bisa diurutkan; di LINQ dapat diselesaikan dengan beberapa ifpernyataan setelahnya.
sparebytes

77

Saya pada umumnya seorang pendukung menempatkan segala sesuatu dalam prosedur yang tersimpan, karena semua alasan DBA telah digunakan selama bertahun-tahun. Dalam kasus Linq, memang benar bahwa tidak akan ada perbedaan kinerja dengan permintaan CRUD sederhana.

Tetapi ingatlah beberapa hal ketika mengambil keputusan ini: menggunakan pasangan ORM mana pun yang dekat dengan model data Anda. DBA tidak memiliki kebebasan untuk melakukan perubahan pada model data tanpa memaksa Anda untuk mengubah kode kompilasi Anda. Dengan prosedur tersimpan, Anda dapat menyembunyikan perubahan semacam ini sampai batas tertentu, karena daftar parameter dan hasil yang dikembalikan dari prosedur mewakili kontraknya, dan jeroan dapat diubah sekitar, selama kontrak itu masih dipenuhi .

Dan juga, jika Linq digunakan untuk query yang lebih kompleks, menyetel basis data menjadi tugas yang jauh lebih sulit. Ketika prosedur tersimpan berjalan lambat, DBA dapat benar-benar fokus pada kode secara terpisah, dan memiliki banyak opsi, hanya agar kontrak tetap puas ketika dia selesai.

Saya telah melihat banyak, banyak kasus di mana masalah serius dalam suatu aplikasi ditangani oleh perubahan pada skema dan kode dalam prosedur tersimpan tanpa ada perubahan pada kode yang dikerahkan dan dikompilasi.

Mungkin pendekatan hybird akan menyenangkan dengan Linq? Linq tentu saja dapat digunakan untuk memanggil prosedur tersimpan.


9
Salah satu fitur yang Anda abaikan adalah keamanan. Dengan Linq, Anda harus memaparkan tabel langsung ke aplikasi. Dengan prosedur tersimpan, Anda dapat membatasi akses ke procs tersebut dan menegakkan persyaratan bisnis Anda.
NotMe

19
"DBA tidak memiliki kebebasan untuk melakukan perubahan pada model data tanpa memaksa Anda untuk mengubah kode kompilasi Anda." Mengapa Anda menganjurkan ini? Tidak seorang pun harus memiliki "kebebasan" untuk melakukan perubahan, itulah tujuan manajemen konfigurasi. Perubahan harus melalui dev, tes, dll sebelum penerapan terlepas.
Neil Barnwell

6
@Neil: Ya, tapi dia tidak bisa membuat perubahan di lingkungan pengembangan tanpa memaksa pengembang untuk mengubah kode.
Adam Robinson

37
Saya harus mengatakan bahwa saya telah melihat banyak argumen tentang penggabungan erat ke basis data, dan saya tidak benar-benar yakin apakah itu valid. Saya tidak pernah benar-benar menemukan situasi (di luar contoh sepele) di mana saya ingin mengubah database yang tidak memerlukan perubahan kode yang lebih tinggi pula. Dan sungguh, bagaimana Linq berbeda dari procs yang disimpan atau permintaan parameterized pula. Lapisan akses data Anda harus tetap dipisahkan dan diabstraksi dengan baik terlepas dari apakah Anda menggunakan ORM atau sesuatu yang lebih sederhana. Itulah yang memberi Anda kopling longgar, bukan teknologi apa yang Anda gunakan. Hanya 2c saya
Simon P Stevens

7
Saya telah melihat 199 prosedur tersimpan yang ditulis secara sia-sia untuk setiap 1 perubahan skema yang dilindungi dari aplikasi melalui tanda tangan SP, tetapi serupa dengan apa yang dikatakan Simon P Stevens, perubahan semantik dalam penggunaan SP memerlukan perubahan aplikasi 100% dari waktu pula. Belum lagi fakta bahwa keberadaan SP hanya memohon beberapa dev atau dba masa depan untuk membocorkan beberapa logika bisnis ke dalam SP. Lalu sedikit lagi, dan sedikit lagi.

64

Linq ke Sql.

Sql server akan men-cache rencana kueri, jadi tidak ada peningkatan kinerja untuk sprocs.

Pernyataan LINQ Anda, di sisi lain, secara logis akan menjadi bagian dan diuji dengan aplikasi Anda. Sprocs selalu sedikit terpisah dan lebih sulit untuk dipertahankan dan diuji.

Jika saya sedang mengerjakan aplikasi baru dari awal sekarang saya hanya akan menggunakan Linq, tidak ada sprocs.


8
Saya tidak setuju tentang komentar Anda tentang tidak ada keuntungan untuk sprocs. Saya memprofilkan serangkaian pendekatan untuk akses SQL Server pada sistem prod, dan menggunakan Mempersiapkan + procs disimpan memiliki hasil terbaik. Bahkan di beberapa panggilan dengan logika yang sama. Mungkin Anda benar pada DB dengan penggunaan rendah.
peringatan

Jika Anda, dan akan menjadi, pengembang permintaan basis data yang paling terampil, maka gunakan apa yang paling Anda kenal. Tidak seperti kode prosedural, Anda tidak bisa mengatakan "jika memberikan jawaban yang tepat, kirimkan."
dkretz

5
@RussellH: Ini benar. Net 3.5, mereka memperbaikinya di .Net 4 (untuk L2S dan L2E)
BlueRaja - Danny Pflughoeft

3
@Kieth Bukan itu masalahnya! Banyak lagi rencana eksekusi dibuat dari Linq daripada SPs. Ada manfaat dengan kode untuk debug; tetapi masalah dengan kompilasi ulang untuk siklus penyebaran perusahaan; tidak fleksibel untuk menguji berbagai pertanyaan AKSI, DI MANA, PESANAN OLEH. Mengubah urutan pernyataan WHERE dapat menyebabkan permintaan yang berbeda diproses; pre-fetching; ini tidak dapat dengan mudah dilakukan di Linq. Perlu memiliki lapisan data yang tersedia untuk tweaker. SPs lebih sulit untuk dirawat dan diuji? Jika Anda tidak terbiasa dengan itu; tetapi SP bermanfaat untuk korps dan VLDB, Ketersediaan Tinggi, dll! Linq untuk proyek kecil, pekerjaan solo; lakukan itu.
SnapJag

4
@SnapJag - Anda benar bahwa sprocs memberi Anda lebih banyak kendali butir, tetapi faktanya 99% dari waktu (bahkan dalam sistem perusahaan tempat saya bekerja), Anda tidak memerlukan pengoptimalan tambahan. Sprocs lebih sulit untuk dipertahankan dan diuji apakah Anda terbiasa atau tidak - saya sangat terbiasa dengan mereka (saya adalah seorang DBA sebelum saya adalah seorang pengembang) dan memastikan bahwa sproc untuk setiap operasi CRUD untuk banyak tabel yang berbeda adalah up to date adalah rasa sakit. Praktik terbaik (IMHO) adalah membuat kode dengan cara yang paling mudah, kemudian jalankan pemeriksaan kinerja dan optimalkan hanya jika diperlukan.
Keith

40

Untuk pengambilan data dasar saya akan pergi untuk Linq tanpa ragu-ragu.

Sejak pindah ke Linq saya telah menemukan keuntungan berikut:

  1. Debugging DAL saya tidak pernah semudah ini.
  2. Kompilasi keamanan waktu saat perubahan skema Anda sangat berharga.
  3. Penempatan lebih mudah karena semuanya dikompilasi ke dalam DLL. Tidak ada lagi mengelola skrip penerapan.
  4. Karena Linq dapat mendukung permintaan apa pun yang mengimplementasikan antarmuka IQueryable, Anda akan dapat menggunakan sintaks yang sama untuk permintaan XML, Objek dan sumber data lainnya tanpa harus mempelajari sintaks baru

1
bagi saya kompilasi keamanan waktu adalah kuncinya!
bbqchickenrobot

Namun untuk penyebaran, jika Anda berada di tim perusahaan yang memiliki siklus penerapan dan ada bug yang perlu keluar dengan cepat, penerapan DLL Anda melalui QA, dll, mungkin lebih ketat daripada jalur penyebaran satu basis data. naskah. Keuntungan Anda tampaknya lebih mewakili skenario tim / proyek kecil.
SnapJag

3
Penempatan skrip SQL yang tidak perlu melalui QA, belum tentu bagus di sini.
liang

27

LINQ akan mengasapi cache prosedur

Jika aplikasi menggunakan LINQ ke SQL dan kueri melibatkan penggunaan string yang panjangnya bisa sangat bervariasi, cache prosedur SQL Server akan menjadi kembung dengan satu versi kueri untuk setiap panjang string yang mungkin. Sebagai contoh, pertimbangkan pertanyaan sangat sederhana berikut yang dibuat terhadap tabel Person.AddressTypes di database AdventureWorks2008:

var p = 
    from n in x.AddressTypes 
    where n.Name == "Billing" 
    select n;

var p = 
    from n in x.AddressTypes 
    where n.Name == "Main Office" 
    select n;

Jika kedua kueri ini dijalankan, kita akan melihat dua entri dalam cache prosedur SQL Server: Satu terikat dengan NVARCHAR (7), dan yang lainnya dengan NVARCHAR (11). Sekarang bayangkan jika ada ratusan atau ribuan string input yang berbeda, semuanya dengan panjang yang berbeda. Cache prosedur akan menjadi tidak perlu diisi dengan segala macam rencana berbeda untuk permintaan yang sama persis.

Lebih lanjut di sini: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363290


10
Apa argumen yang konyol - cukup gunakan variabel dan masalah Anda terpecahkan.
JohnOpincar

6
@ John, tidak akan membantu jika Anda menggunakan validasi daripada string literal karena pada akhirnya Anda mengirim string literal ke database. mungkin terlihat seperti variabel dalam kode Anda, tetapi itu akan menjadi string dalam T-SQL yang dihasilkan yang dikirim ke DB.
kay.one

15
SQLMenace: Menurut halaman yang Anda tautkan, masalah terpecahkan di VS2010.
Mark Byers

8
Masalah ini valid ketika jawaban diposting, tetapi sejak itu telah dipecahkan di VS2010, sehingga tidak lagi menjadi masalah.
Brain2000

17

Saya pikir argumen pro LINQ tampaknya berasal dari orang-orang yang tidak memiliki sejarah dengan pengembangan basis data (secara umum).

Terutama jika menggunakan produk seperti VS DB Pro atau Team Suite, banyak argumen yang dibuat di sini tidak berlaku, misalnya:

Sulit untuk mempertahankan dan Menguji: VS menyediakan pemeriksaan sintaksis lengkap, pengecekan gaya, pengecekan referensial dan kendala dan banyak lagi. Ini juga menyediakan kemampuan pengujian unit lengkap dan alat refactoring.

LINQ membuat pengujian unit yang benar tidak mungkin karena (dalam pikiran saya) gagal tes ACID.

Debugging lebih mudah di LINQ: Mengapa? VS memungkinkan step-in penuh dari kode terkelola dan debugging SP secara teratur.

Dikompilasi menjadi satu DLL daripada skrip penerapan: Sekali lagi, VS datang untuk menyelamatkan di mana ia dapat membangun dan menggunakan basis data lengkap atau membuat perubahan tambahan yang aman data.

Tidak harus belajar TSQL dengan LINQ: Tidak, tetapi Anda harus belajar LINQ - di mana manfaatnya?

Saya benar-benar tidak melihat ini sebagai manfaat. Mampu mengubah sesuatu dalam isolasi mungkin terdengar bagus secara teori, tetapi hanya karena perubahan memenuhi kontrak tidak berarti itu mengembalikan hasil yang benar. Untuk dapat menentukan hasil yang benar, Anda memerlukan konteks dan Anda mendapatkan konteks itu dari kode panggilan.

Um, aplikasi yang digabungkan secara longgar adalah tujuan akhir dari semua programmer yang baik karena mereka benar-benar meningkatkan fleksibilitas. Mampu mengubah hal-hal dalam isolasi itu fantastis, dan tes unit Anda yang akan memastikan itu masih memberikan hasil yang sesuai.

Sebelum kalian semua kesal, saya pikir LINQ memiliki tempatnya dan memiliki masa depan yang cerah. Tetapi untuk aplikasi yang kompleks dan intensif data, saya pikir tidak siap untuk menggantikan prosedur yang tersimpan. Ini adalah pandangan yang saya gaungkan oleh seorang MVP di TechEd tahun ini (mereka akan tetap tanpa nama).

EDIT: Sisi LINQ to SQL Stored Procedure adalah sesuatu yang masih perlu saya baca lebih lanjut - tergantung pada apa yang saya temukan saya dapat mengubah cacian saya di atas;)


4
Belajar LINQ bukan masalah besar - itu hanya gula sintaksis. TSQL adalah bahasa yang sama sekali berbeda. Apel dan Jeruk.
Adam Lassek

3
Manfaat dari belajar LINQ adalah tidak terkait dengan satu teknologi - semantik kueri dapat digunakan untuk XML, objek, dan sebagainya, dan ini akan berkembang seiring waktu.
Dave R.

5
Sepakat! Begitu banyak orang (pengembang) mencari solusi "kecepatan-ke-pasar" dalam tim dan proyek kecil. Tetapi jika pengembangannya ditingkatkan ke tingkat gaya korporat berikutnya dengan banyak tim, basis data besar, volume tinggi, ketersediaan tinggi, sistem terdistribusi, akan berbeda jika menggunakan LINQ! Saya tidak percaya Anda perlu mengedit opini Anda terlalu lama. LINQ bukan untuk proyek / tim yang lebih besar dan memiliki banyak orang, banyak tim (Pengembang & DBA), DAN memiliki jadwal penyebaran yang ketat.
SnapJag

17

LINQ baru dan memiliki tempatnya. LINQ tidak ditemukan untuk menggantikan prosedur tersimpan.

Di sini saya akan fokus pada beberapa mitos kinerja & KONTRA, hanya untuk "LINQ to SQL", tentu saja saya mungkin benar-benar salah ;-)

(1) Orang mengatakan statemen LINQ dapat "cache" di SQL server, sehingga tidak kehilangan kinerja. Sebagian benar. "LINQ to SQL" sebenarnya adalah runtime yang menerjemahkan sintaks LINQ ke statemen TSQL. Jadi dari perspektif kinerja, pernyataan SQL ADO.NET kode keras tidak memiliki perbedaan dari LINQ.

(2) Diberikan contoh, UI layanan pelanggan memiliki fungsi "transfer akun". fungsi ini sendiri dapat memperbarui 10 tabel DB dan mengembalikan beberapa pesan dalam satu kesempatan. Dengan LINQ, Anda harus membuat satu set pernyataan dan mengirimkannya sebagai satu batch ke SQL server. kinerja terjemahan LINQ-> TSQL yang diterjemahkan ini hampir tidak dapat menyamai prosedur tersimpan. Alasan? karena Anda dapat men-tweak unit terkecil dari pernyataan dalam prosedur Stored dengan menggunakan alat profiler SQL dan rencana eksekusi, Anda tidak dapat melakukan ini di LINQ.

Intinya adalah, ketika berbicara tabel DB tunggal dan set kecil data CRUD, LINQ secepat SP. Tetapi untuk logika yang jauh lebih rumit, prosedur tersimpan lebih mengutak atik kinerja.

(3) "LINQ to SQL" dengan mudah membuat pemula untuk memperkenalkan babi kinerja. Setiap pria senior TSQL dapat memberi tahu Anda kapan tidak menggunakan CURSOR (Pada dasarnya Anda tidak boleh menggunakan CURSOR dalam TSQL dalam banyak kasus). Dengan LINQ dan loop "foreach" yang menawan dengan kueri, sangat mudah bagi seorang pemula untuk menulis kode seperti itu:

foreach(Customer c in query)
{
  c.Country = "Wonder Land";
}
ctx.SubmitChanges();

Anda dapat melihat kode yang layak dan mudah ini sangat menarik. Tetapi di bawah tenda, .NET runtime hanya menerjemahkan ini ke kumpulan pembaruan. Jika hanya ada 500 baris, ini adalah 500 baris batch TSQL; Jika ada jutaan baris, ini adalah hit. Tentu saja, pengguna berpengalaman tidak akan menggunakan cara ini untuk melakukan pekerjaan ini, tetapi intinya adalah, sangat mudah untuk jatuh dengan cara ini.


2
mudah gagal dengan pointer di C / C ++ / C # apakah itu berarti itu tidak boleh digunakan?
bbqchickenrobot

1
Berapa banyak programmer tingkat menengah menangani pointer? Linq memaparkan kemampuan ini ke level coder mana pun yang berarti risiko kesalahan meningkat secara dramatis.
Jacques

1
Anda membandingkan pemula di LINQ dengan pria senior TSQL. Tidak benar-benar perbandingan yang adil. Saya setuju dengan kode Anda, LINQ tidak berkinerja untuk pembaruan batch / menghapus secara umum. Namun, saya berpendapat sebagian besar argumen kinerja antara LINQ dan SP, adalah klaim, tetapi tidak didasarkan pada ukuran
liang

12

Kode terbaik adalah tanpa kode, dan dengan prosedur tersimpan Anda harus menulis setidaknya beberapa kode dalam database dan kode dalam aplikasi untuk memanggilnya, sedangkan dengan LINQ ke SQL atau LINQ ke Entitas, Anda tidak perlu menulis tambahan kode di luar kueri LINQ lain selain dari instantiating objek konteks.


10

LINQ jelas memiliki tempat dalam database khusus aplikasi dan dalam bisnis kecil.

Tetapi dalam perusahaan besar, di mana basis data pusat berfungsi sebagai pusat data umum untuk banyak aplikasi, kita perlu abstraksi. Kita perlu mengelola keamanan secara terpusat dan menunjukkan riwayat akses. Kita harus dapat melakukan analisis dampak: jika saya membuat sedikit perubahan pada model data untuk melayani kebutuhan bisnis baru, pertanyaan apa yang perlu diubah dan aplikasi apa yang perlu diuji ulang? Tampilan dan Prosedur Tersimpan memberi saya itu. Jika LINQ dapat melakukan semua itu, dan membuat programmer kami lebih produktif, saya akan menyambutnya - apakah ada yang punya pengalaman menggunakannya di lingkungan seperti ini?


2
Anda memunculkan poin yang bagus; LINQ bukan merupakan alternatif dalam hal ini.
Meta-Knight

1
Berbagai aplikasi Anda semua harus menggunakan lapisan akses data umum (tentu saja, itu tidak selalu terjadi). Jika demikian, maka, Anda dapat membuat satu perubahan ke perpustakaan umum dan memindahkan kembali. Anda juga dapat menggunakan sesuatu seperti WCF untuk menangani akses data untuk Anda. Ada lapisan abstraksi yang bagus yang secara teknis bisa menggunakan LINQ untuk mengakses data di belakang layar. Saya kira itu semua tergantung pada apa yang orang-orang Anda buat untuk persyaratan Anda dalam hal menggunakan SPs vs Linq.
bbqchickenrobot

8

DBA tidak memiliki kebebasan untuk melakukan perubahan pada model data tanpa memaksa Anda untuk mengubah kode kompilasi Anda. Dengan prosedur tersimpan, Anda dapat menyembunyikan perubahan semacam ini sampai batas tertentu, karena daftar parameter dan hasil yang dikembalikan dari prosedur mewakili kontraknya, dan jeroan dapat diubah sekitar, selama kontrak itu masih dipenuhi .

Saya benar-benar tidak melihat ini sebagai manfaat. Mampu mengubah sesuatu dalam isolasi mungkin terdengar bagus secara teori, tetapi hanya karena perubahan memenuhi kontrak tidak berarti itu mengembalikan hasil yang benar. Untuk dapat menentukan hasil yang benar, Anda memerlukan konteks dan Anda mendapatkan konteks itu dari kode panggilan.


7

IMHO, RAD = LINQ, RUP = Procs Tersimpan. Saya bekerja untuk perusahaan besar Fortune 500 selama bertahun-tahun, di banyak tingkatan termasuk manajemen, dan terus terang, saya tidak akan pernah mempekerjakan pengembang RUP untuk melakukan pengembangan RAD. Mereka begitu diam sehingga pengetahuan mereka sangat terbatas tentang apa yang harus dilakukan di tingkat proses yang lain. Dengan lingkungan yang sunyi, masuk akal untuk memberikan kontrol DBA atas data melalui titik masuk yang sangat spesifik, karena yang lain terus terang tidak tahu cara terbaik untuk mencapai manajemen data.

Tetapi perusahaan besar bergerak dengan menyakitkan lambat di arena pengembangan, dan ini sangat mahal. Ada kalanya Anda perlu bergerak lebih cepat untuk menghemat waktu dan uang, dan LINQ menyediakan itu dan lebih banyak lagi dalam sekop.

Kadang-kadang saya berpikir bahwa DBA bias terhadap LINQ karena mereka merasa itu mengancam keamanan pekerjaan mereka. Tapi itulah sifat binatang itu, tuan dan nyonya.


3
Ya, kami para DBA duduk-duduk menunggu sepanjang hari untuk Anda meminta dorongan Proc Disimpan untuk produksi. Tidak harus melakukan itu akan menghancurkan hati kita!
Sam

6

Saya pikir Anda perlu menggunakan procs untuk sesuatu yang nyata.

A) Menulis semua logika Anda dalam LINQ berarti database Anda kurang berguna karena hanya aplikasi Anda yang dapat menggunakannya.

B) Saya tidak yakin bahwa pemodelan objek lebih baik daripada pemodelan relasional.

C) Menguji dan mengembangkan prosedur tersimpan dalam SQL jauh lebih cepat daripada siklus edit kompilasi di lingkungan Visual Studio. Anda cukup mengedit, F5 dan tekan pilih dan Anda pergi ke balapan.

D) Lebih mudah untuk mengelola dan menggunakan prosedur tersimpan daripada rakitan .. Anda cukup meletakkan file di server, dan tekan F5 ...

E) Linq to sql masih menulis kode jelek pada saat Anda tidak mengharapkannya.

Jujur, saya pikir hal yang paling penting bagi MS untuk menambah t-sql sehingga dapat melakukan proyeksi gabungan secara implisit seperti cara LINQ. t-sql harus tahu jika Anda ingin melakukan order.lineitems.part, misalnya.


5

LINQ tidak melarang penggunaan prosedur yang tersimpan. Saya telah menggunakan mode campuran dengan LINQ-SQL dan LINQ-storedproc . Secara pribadi, saya senang saya tidak harus menulis procs yang tersimpan .... pwet-tu.


4

Juga, ada masalah kemungkinan 2.0 rollback. Percayalah, itu sudah terjadi pada saya beberapa kali, jadi saya yakin itu terjadi pada orang lain.

Saya juga setuju bahwa abstraksi adalah yang terbaik. Seiring dengan kenyataan, tujuan awal ORM adalah untuk membuat RDBMS cocok dengan konsep OO. Namun, jika semuanya bekerja dengan baik sebelum LINQ dengan harus menyimpang sedikit dari konsep OO maka sekrup mereka. Konsep dan kenyataan tidak selalu cocok bersama. Tidak ada ruang untuk fanatik militan di TI.


3

Saya berasumsi maksudmu Linq To Sql

Untuk setiap perintah CRUD, sangat mudah untuk membuat profil kinerja prosedur tersimpan vs teknologi apa pun. Dalam hal ini perbedaan antara keduanya akan diabaikan. Cobalah membuat profil untuk objek bidang 5 (tipe sederhana) lebih dari 100.000 kueri pemilihan untuk mengetahui apakah ada perbedaan nyata.

Di sisi lain, real deal-breaker akan menjadi pertanyaan apakah Anda merasa nyaman menempatkan logika bisnis Anda di database Anda atau tidak, yang merupakan argumen terhadap prosedur tersimpan.


1
Karena lebih banyak tempat daripada aplikasi dapat mempengaruhi data - impor data, aplikasi lain, permintaan langsung, dll. Adalah bodoh untuk tidak memasukkan logika bisnis ke dalam basis data. Tetapi jika integritas data tidak menjadi perhatian Anda, silakan.
HLGEM

3
Logika bisnis tidak boleh masuk ke dalam database. Itu harus dalam bahasa pemrograman di mana ia mudah didebug dan dikelola. Kemudian dapat dibagikan di seluruh aplikasi sebagai objek. Beberapa aturan mungkin ada dalam database tetapi tidak logika bisnis.
4thSpace

3

Menurut guru, saya mendefinisikan LINQ sebagai sepeda motor dan SP sebagai mobil. Jika Anda ingin melakukan perjalanan singkat dan hanya memiliki penumpang kecil (dalam hal ini 2), pergi dengan anggun dengan LINQ. Tetapi jika Anda ingin melakukan perjalanan dan memiliki band besar, saya pikir Anda harus memilih SP.

Sebagai kesimpulan, memilih antara sepeda motor atau mobil tergantung pada rute Anda (bisnis), panjang (waktu), dan penumpang (data).

Semoga ini bisa membantu, saya mungkin salah. : D


1
teman - teman meninggal karena mengendarai sepeda motor: P
Alex

2
orang tewas mengendarai mobil juga.
liang

1
ya kamu salah.
Asad Ali

3

Semua jawaban ini condong ke LINQ terutama berbicara tentang EASE of DEVELOPMENT yang lebih atau kurang terhubung dengan kualitas buruk coding atau malas dalam coding. Saya hanya seperti itu.

Beberapa keuntungan atau Linq, saya baca di sini sebagai, mudah untuk diuji, mudah untuk debug dll, tetapi ini tidak ada tempat yang terhubung ke hasil akhir atau pengguna akhir. Ini selalu akan menyebabkan masalah pengguna akhir pada kinerja. Apa gunanya memuat banyak hal dalam memori dan kemudian menerapkan filter dalam menggunakan LINQ?

Sekali lagi TypeSafety, berhati-hati bahwa "kami berhati-hati untuk menghindari kesalahan typecasting" yang lagi-lagi kualitas buruk kami coba tingkatkan dengan menggunakan LINQ. Bahkan dalam kasus itu, jika ada perubahan database, misalnya ukuran kolom String, maka LINQ perlu dikompilasi ulang dan tidak akan menjadi typesafe tanpa itu .. Saya mencoba.

Meskipun, kami menemukan itu baik, manis, menarik dll saat bekerja dengan LINQ, itu memiliki kerugian geser membuat pengembang malas :) dan terbukti 1000 kali itu buruk (mungkin terburuk) pada kinerja dibandingkan dengan Stored Procs.

Berhentilah menjadi malas. Saya berusaha keras. :)


4
Memuat semua yang ada di memori dan memfilternya? Linq dapat mengirim filter sebagai bagian dari permintaan ke database, dan mengembalikan set hasil yang difilter.
liang

ada beberapa orang yang percaya bahwa LINQ memuat semua data dan memprosesnya menggunakan foreach loop. Itu salah. Itu hanya akan dikompilasi ke dalam query sql dan memberikan kinerja yang hampir sama untuk sebagian besar operasi CRUD. Tapi ya itu bukan peluru perak. Ada kasus di mana menggunakan T-SQL atau procs yang disimpan dapat berubah menjadi lebih baik.
Ini jebakan

Saya setuju dengan kedua argumen kontra. Namun, tidak sepenuhnya benar bahwa LINQ mengirim semua filter ke DBMS untuk mengerjakannya. Ada beberapa hal yang berfungsi dalam memori salah satunya berbeda.
Manish

2

Untuk operasi CRUD sederhana dengan titik akses data tunggal, saya akan mengatakan pergi untuk LINQ jika Anda merasa nyaman dengan sintaks. Untuk logika yang lebih rumit saya pikir sprocs lebih efisien kinerja-bijaksana jika Anda pandai T-SQL dan operasi yang lebih maju. Anda juga mendapat bantuan dari Tuning Advisor, SQL Server Profiler, men-debug permintaan Anda dari SSMS dll.


2

Prosedur tersimpan membuat pengujian lebih mudah dan Anda dapat mengubah kueri tanpa menyentuh kode aplikasi. Juga dengan LINQ, mendapatkan data tidak berarti itu data yang tepat. Dan menguji kebenaran data berarti menjalankan aplikasi tetapi dengan prosedur tersimpan mudah untuk menguji tanpa menyentuh aplikasi.


1

Hasilnya dapat diringkas sebagai

LinqToSql untuk situs kecil, dan prototipe. Ini benar-benar menghemat waktu untuk Prototyping.

Sps: Universal. Saya dapat memperbaiki pertanyaan saya dan selalu memeriksa ActualExecutionPlan / EstimatedExecutionPlan.



0

LINQ dan SQL memiliki tempat masing-masing. Keduanya memiliki kekurangan dan kelebihan masing-masing.

Terkadang untuk pengambilan data yang kompleks, Anda mungkin perlu menyimpan procs. Dan terkadang Anda mungkin ingin orang lain menggunakan proc Anda yang tersimpan di Sql Server Management Studio.

Linq to Entities sangat bagus untuk pengembangan CRUD yang cepat.

Tentu Anda dapat membangun aplikasi hanya menggunakan satu atau yang lain. Atau Anda bisa mencampurnya. Itu semua bermuara pada kebutuhan Anda. Tetapi procs yang disimpan SQL tidak akan hilang dalam waktu dekat.

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.