Saya bekerja di perusahaan yang hanya menggunakan prosedur tersimpan untuk semua akses data, yang membuatnya sangat menjengkelkan untuk menjaga database lokal kami tetap sinkron karena setiap komit kami harus menjalankan procs baru. Saya telah menggunakan beberapa ORM dasar di masa lalu dan saya menemukan pengalamannya jauh lebih baik dan lebih bersih. Saya ingin menyarankan kepada manajer pengembangan dan seluruh tim bahwa kami ingin menggunakan ORM untuk pengembangan di masa mendatang (anggota tim lainnya hanya mengenal prosedur tersimpan dan tidak pernah menggunakan hal lain). Arsitektur saat ini adalah .NET 3.5 ditulis seperti .NET 1.1, dengan "kelas dewa" yang menggunakan implementasi ActiveRecord yang aneh dan mengembalikan set data yang tidak diketik yang di-loop dalam file kode-belakang - kelas bekerja seperti ini:
class Foo {
public bool LoadFoo() {
bool blnResult = false;
if (this.FooID == 0) {
throw new Exception("FooID must be set before calling this method.");
}
DataSet ds = // ... call to Sproc
if (ds.Tables[0].Rows.Count > 0) {
foo.FooName = ds.Tables[0].Rows[0]["FooName"].ToString();
// other properties set
blnResult = true;
}
return blnResult;
}
}
// Consumer
Foo foo = new Foo();
foo.FooID = 1234;
foo.LoadFoo();
// do stuff with foo...Hampir tidak ada aplikasi dari pola desain. Tidak ada tes apa pun (tidak ada orang lain yang tahu cara menulis unit test, dan pengujian dilakukan melalui memuat situs web secara manual dan melihat-lihat). Melihat melalui database kami, kami memiliki: 199 tabel, 13 tampilan, 926 prosedur tersimpan dan 93 fungsi. Sekitar 30 atau lebih tabel digunakan untuk pekerjaan batch atau hal-hal eksternal, sisanya digunakan dalam aplikasi inti kami.
Apakah layak melakukan pendekatan yang berbeda dalam skenario ini? Saya berbicara tentang bergerak maju hanya karena kami tidak diizinkan untuk memperbaiki kode yang ada sejak "itu berfungsi" sehingga kami tidak dapat mengubah kelas yang ada untuk menggunakan ORM, tetapi saya tidak tahu seberapa sering kami menambahkan modul baru sebagai gantinya menambahkan / memperbaiki modul saat ini jadi saya tidak yakin apakah ORM adalah pendekatan yang tepat (terlalu banyak diinvestasikan dalam prosedur dan DataSet yang tersimpan). Jika itu pilihan yang tepat, bagaimana saya harus menyajikan kasing untuk menggunakannya? Dari atas kepala saya satu-satunya manfaat yang dapat saya pikirkan adalah memiliki kode pembersih (walaupun mungkin tidak, karena arsitektur saat ini bukan T dibangun dengan ORM dalam pikiran sehingga kita pada dasarnya akan menjadi ORM juri-rigging ke modul masa depan tetapi yang lama masih akan menggunakan DataSet) dan lebih mudah untuk mengingat prosedur skrip apa yang telah dijalankan dan yang perlu dijalankan, dll. tapi itu saja, dan saya tidak tahu bagaimana menariknya argumen itu. Kemampu-rawatan adalah masalah lain tetapi yang tidak diperhatikan oleh siapa pun kecuali saya.
sumber
Jawaban:
Prosedur tersimpan buruk, seringkali lambat dan kira-kira seefisien kode sisi klien biasa.
[Speedup biasanya disebabkan oleh cara klien dan antarmuka prosedur tersimpan dirancang dan cara transaksi ditulis sebagai semburan SQL pendek dan terfokus.]
Prosedur tersimpan adalah salah satu tempat terburuk untuk meletakkan kode. Ini memecah aplikasi Anda menjadi dua bahasa dan platform sesuai dengan aturan yang seringkali acak.
[Pertanyaan ini akan diturunkan untuk memiliki skor sekitar -30 karena banyak, banyak orang merasa bahwa prosedur tersimpan memiliki kekuatan magis dan harus digunakan terlepas dari masalah yang mereka sebabkan.]
Memindahkan semua kode prosedur yang tersimpan ke klien akan membuat segalanya lebih mudah bagi semua orang.
Anda masih harus memperbarui skema dan model ORM dari waktu ke waktu. Namun, perubahan skema terisolasi dari perubahan ORM, memungkinkan beberapa independensi antara aplikasi dan skema database.
Anda akan dapat menguji, memperbaiki, memelihara, memahami dan mengadaptasi semua prosedur yang tersimpan saat Anda menulis ulang. Aplikasi Anda akan berjalan hampir sama dan menjadi jauh lebih rapuh karena Anda tidak lagi membobol dua teknologi yang berbeda.
ORM bukanlah sihir, dan keterampilan desain database yang baik sangat penting untuk membuatnya berfungsi.
Juga, program dengan banyak klien SQL dapat menjadi lambat karena pemikiran yang buruk tentang batasan transaksi. Salah satu alasan prosedur tersimpan tampaknya cepat adalah bahwa prosedur tersimpan memaksa desain transaksi yang sangat, sangat hati-hati.
ORM tidak secara ajaib memaksakan desain transaksi yang hati-hati. Desain transaksi masih harus dilakukan dengan hati-hati seperti ketika menulis prosedur tersimpan.
sumber
Prosedur tersimpan baik, cepat dan sangat efisien dan merupakan tempat yang ideal untuk meletakkan kode Anda yang berhubungan dengan data. Memindahkan semua kode itu ke klien akan membuat segalanya sedikit lebih mudah bagi Anda sebagai pengembang klien (sedikit, karena Anda masih harus memperbarui skema dan model ORM ketika komit mengubahnya) tetapi Anda akan kehilangan semua kode yang ada, dan membuat aplikasi Anda lebih lambat dan mungkin lebih rapuh mengingat hilangnya semua keterampilan sql tersebut.
Saya bertanya-tanya apakah DBA duduk di sana berkata "oh, setiap komit, saya harus menarik klien lagi, kita harus memindahkan semua kode ke dalam bentuk DB sebagai gantinya".
Dalam kasus Anda, Anda harus dapat mengganti ORM kustom yang ada (yaitu kelas lucu Anda) dengan orang lain tanpa kehilangan apa pun kecuali perubahan cara penulisan kode di belakang kode Anda. Anda dapat menyimpan SP juga karena kebanyakan (semua?) ORM akan dengan senang hati memanggil mereka. Jadi, saya akan merekomendasikan mengganti kelas "Foo" dengan ORM dan pergi dari sana. Saya tidak akan merekomendasikan mengganti SP Anda.
PS. Tampaknya Anda memiliki banyak kode umum di kelas kode-belakang, yang menjadikannya pola desain tersendiri. Menurut Anda apa pola desain di tempat pertama! (ok, itu mungkin bukan yang terbaik, atau bahkan yang bagus, tapi itu masih DP)
Sunting: dan sekarang dengan Dapper , alasan apa pun untuk menghindari sprocs pada ORM kelas berat hilang.
sumber
ds.Tables[0].Rows[0]["FooName"].ToString()omong kosong itu. Manajer menyukai prosedur tersimpan? Dia harus menjaga mereka. Tetapi secara fisik tidak mungkin untuk berpendapat bahwa memindahkan semua kode boilerplate berulang menjadi sesuatu yang dihasilkan oleh, katakanlah, LINQ ke SQL, adalah hal yang buruk.Anda tampaknya mencoba memimpin tim Anda dari satu ekstrem (prosedur dan set data tersimpan) ke yang lain (ORM lengkap). Saya pikir ada beberapa perubahan tambahan lainnya yang dapat Anda tetapkan tentang penerapan untuk meningkatkan kualitas kode lapisan akses data Anda, yang mungkin lebih bersedia diterima oleh tim Anda.
Kode implementasi active-record setengah matang yang Anda posting tidak terlalu bagus - saya akan merekomendasikan meneliti Pola Repositori yang mudah dimengerti dan diimplementasikan, dan sangat populer di kalangan pengembang .NET. Pola ini sering dikaitkan dengan ORM tetapi sangat mudah untuk membuat repositori menggunakan ADO.NET biasa.
Adapun DataSet - yuck! Pustaka kelas Anda akan lebih mudah digunakan jika Anda mengembalikan objek yang diketik secara statis (atau bahkan dinamis). Saya percaya ilustrasi ini menjelaskan pendapat saya tentang DataSet lebih baik daripada yang saya bisa.
Juga, Anda dapat membuang proc yang disimpan tanpa melompat ke ORM - tidak ada yang salah dengan menggunakan SQL parameterised. Bahkan saya pasti lebih suka menggunakan proc yang tersimpan kecuali jika Anda memiliki prosedur rumit yang menghemat beberapa perjalanan pulang-pergi ke server. Saya juga benci ketika saya membuka basis data warisan dan melihat daftar prosedur CRUD yang tak ada habisnya.
Saya tidak mengecilkan penggunaan ORM - saya biasanya menggunakannya pada sebagian besar proyek yang saya kerjakan. Namun saya dapat melihat mengapa mungkin ada banyak gesekan dalam mencoba memperkenalkan satu ke dalam proyek ini dan tim Anda yang dengan ramah, terdengar seperti mereka berhenti mempelajari hal-hal baru sekitar 8 tahun yang lalu. Setelah mengatakan bahwa saya pasti akan melihat generasi baru "Micro ORM's" seperti Dapper (digunakan untuk memberi daya pada situs ini tidak kurang) dan Massive , keduanya sangat mudah digunakan dan membuat Anda lebih dekat ke SQL daripada ORM tipikal melakukannya, dan tim mana yang mungkin lebih bersedia untuk menerima.
sumber
Saya berada dalam situasi yang sama, sebenarnya perangkat keras, kekuatan, dan politik kita condong ke sisi basis data, jadi semuanya berjalan melalui prosedur tersimpan. Sayangnya, mereka merepotkan seorang pembuat kode, terutama dalam hal metadata dan pembuatan kode, karena tidak ada data meta yang kaya dalam prosedur tersimpan seperti tabel.
Apapun, Anda masih dapat menulis kode yang elegan, dan membersihkan menggunakan procs yang disimpan. Saat ini saya sedang menerapkan pola Repositori sendiri dengan semua prosedur yang tersimpan. Saya sarankan melihat FluentAdo.net untuk ide cemerlang ketika memetakan dari datareader kembali ke objek bisnis Anda. Saya mengambil sebagian dari ide itu, dan menggunakan kembali untuk solusi yang saya buat sendiri.
sumber
JFTR - Saya adalah pengembang PHP rendahan, tapi ini kedengarannya seperti masalah politik yang dominan.
Mengingat skala "membusuk" menopang aplikasi, maka - selain praktik terbaik - akan ada overhead yang signifikan untuk root. Ini sepertinya berbatasan dengan wilayah penulisan ulang.
Bisakah Anda menjamin bahwa alternatif yang Anda sarankan akan menghasilkan manfaat untuk membenarkan biaya untuk bisnis? Saya menduga bahwa ROI dari usaha ini mungkin sulit dijual ke bisnis. Kecuali jika aplikasinya tidak stabil, atau Anda dapat membuktikan manfaat perbaikan secara finansial - ini mungkin terbukti sulit.
Apakah ORM satu - satunya alternatif untuk SPROCS? Ada beberapa pola desain antara ORM yang penuh sesak nafas dan vanilla SQL. Mungkin Anda bisa memulai proses dengan membawa SPROCS ini secara bertahap dari DB ke dalam DBAL. Ada bahaya tentu saja bahwa ini akan tumbuh menjadi ORM homebrew dari waktu ke waktu - tetapi Anda harus selangkah lebih dekat ke tujuan.
sumber
Kami beralih dari SP ke ORM beberapa tahun yang lalu.
Dalam satu kasus, kami harus memperbarui 80 tabel. Model estimasi lama akan memperkirakan 80 jam untuk ini dengan entlib dan SP. Kami melakukannya dalam 10 :)
Ini telah memberi kami pengurangan 80% dalam jumlah waktu yang kami gunakan untuk mengembangkan lapisan akses data.
sumber
Bagi saya, masalahnya adalah bahwa penyebaran Anda tidak berfungsi dengan benar dan otomatis.
Mungkin lebih mudah untuk membuat mesin build kontinu yang tahu bagaimana memanipulasi database sesuai kebutuhan setelah setiap komit.
sumber