Setelah menggunakan Hibernate di sebagian besar proyek saya selama sekitar 8 tahun, saya telah mendarat di sebuah perusahaan yang tidak mendukung penggunaannya dan ingin aplikasi hanya berinteraksi dengan DB melalui prosedur tersimpan.
Setelah melakukan ini selama beberapa minggu, saya belum dapat membuat model domain yang kaya dari aplikasi yang saya mulai buat, dan aplikasi tersebut hanya terlihat seperti skrip transaksional (mengerikan).
Beberapa masalah yang saya temukan adalah:
- Tidak dapat menavigasi grafik objek karena prosedur yang tersimpan hanya memuat jumlah data minimum, yang berarti bahwa kadang-kadang kita memiliki objek serupa dengan bidang yang berbeda. Salah satu contoh adalah: kami memiliki prosedur tersimpan untuk mengambil semua data dari pelanggan, dan yang lain untuk mengambil informasi akun ditambah beberapa bidang dari pelanggan.
- Banyak logika berakhir di kelas pembantu, sehingga kode menjadi lebih terstruktur (dengan entitas yang digunakan sebagai struct C lama).
- Kode perancah yang lebih membosankan, karena tidak ada kerangka kerja yang mengekstrak set hasil dari prosedur yang disimpan dan menempatkannya dalam suatu entitas.
Pertanyaan saya adalah:
- Adakah yang pernah berada dalam situasi yang sama dan tidak setuju dengan pendekatan prosedur toko? apa yang kamu lakukan?
- Apakah ada manfaat sebenarnya dari menggunakan prosedur tersimpan? terlepas dari titik konyol "tidak ada yang bisa mengeluarkan drop table".
- Apakah ada cara untuk membuat domain kaya menggunakan prosedur tersimpan? Saya tahu bahwa ada kemungkinan menggunakan AOP untuk menyuntikkan DAO / Repositori ke entitas untuk dapat menavigasi objek grafik. Saya tidak suka opsi ini karena sangat dekat dengan voodoo.
Kesimpulan
Pertama, terima kasih atas jawaban Anda. Kesimpulan yang saya sampaikan adalah bahwa ORM tidak memungkinkan pembuatan model Rich Domain (seperti beberapa orang sebutkan), tetapi itu menyederhanakan jumlah pekerjaan (sering berulang). Berikut ini adalah penjelasan yang lebih rinci tentang kesimpulan, tetapi tidak didasarkan pada data keras apa pun.
Sebagian besar aplikasi meminta dan mengirim informasi ke sistem lain. Untuk melakukan ini, kami membuat abstraksi dalam ketentuan model (misalnya acara bisnis) dan model domain mengirim atau menerima acara. Peristiwa biasanya membutuhkan sebagian kecil informasi dari model, tetapi tidak keseluruhan model. Misalnya di toko online, gateway pembayaran meminta beberapa informasi pengguna dan total untuk menagih pengguna, tetapi tidak memerlukan riwayat pembelian, produk yang tersedia, dan semua basis pelanggan. Jadi acara tersebut memiliki set data kecil dan spesifik.
Jika kita mengambil database aplikasi sebagai sistem eksternal, maka kita perlu membuat abstraksi yang memungkinkan kita untuk memetakan entitas Model Domain ke database ( seperti yang NimChimpsky sebutkan , menggunakan data-mapper). Perbedaan yang jelas, adalah bahwa sekarang kita perlu membuat pemetaan untuk setiap entitas model ke basis data (baik skema lama atau prosedur tersimpan), dengan rasa sakit tambahan bahwa, karena keduanya tidak sinkron, satu entitas domain mungkin memetakan sebagian ke entitas basis data (misalnya kelas UserCredentials yang hanya berisi nama pengguna dan kata sandi dipetakan ke tabel Pengguna yang memiliki kolom lain), atau satu entitas model domain dapat memetakan ke lebih dari satu entitas basis data (misalnya jika ada satu-ke- satu pemetaan di atas meja, tetapi kami ingin semua data hanya dalam satu kelas).
Dalam aplikasi dengan beberapa entitas, jumlah pekerjaan tambahan mungkin kecil jika tidak perlu melintangi entitas, tetapi meningkat ketika ada kebutuhan bersyarat untuk melintangi entitas (dan dengan demikian kita mungkin ingin menerapkan semacam 'malas' pemuatan'). Ketika sebuah aplikasi tumbuh memiliki lebih banyak entitas, pekerjaan ini hanya meningkat (dan saya merasa bahwa itu meningkat secara non-linear). Asumsi saya di sini, adalah bahwa kita tidak mencoba untuk menemukan kembali ORM.
Salah satu manfaat memperlakukan DB sebagai sistem eksternal, adalah kita dapat membuat kode di sekitar situasi di mana kita menginginkan 2 versi berbeda dari aplikasi yang berjalan, di mana setiap aplikasi memiliki pemetaan yang berbeda. Ini menjadi lebih menarik dalam skenario pengiriman kontinu ke produksi ... tapi saya pikir ini juga dimungkinkan dengan ORM pada tingkat yang lebih rendah.
Saya akan mengabaikan aspek keamanan, atas dasar bahwa pengembang, bahkan jika dia tidak memiliki akses ke database, dapat memperoleh sebagian besar jika tidak semua informasi yang disimpan dalam sistem, hanya dengan menyuntikkan kode berbahaya (mis. Saya tidak percaya saya lupa menghapus garis yang mencatat rincian kartu kredit pelanggan, Tuanku! ).
Pembaruan kecil (6/6/2012)
Prosedur tersimpan (setidaknya dalam Oracle) mencegah melakukan apa pun seperti pengiriman terus-menerus dengan Zero downtime, karena setiap perubahan pada struktur tabel akan membatalkan prosedur dan pemicu. Jadi selama DB diperbarui, aplikasi akan turun juga. Oracle memberikan solusi untuk Redefinisi Berbasis Edisi ini , tetapi beberapa DBA yang saya tanyakan tentang fitur ini menyebutkan bahwa itu diimplementasikan dengan buruk dan mereka tidak akan memasukkannya ke dalam DB produksi.