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.