Apa manfaat menggunakan abstraksi basis data oleh ORM? [Tutup]


19

Saya mulai menggunakan ORM yang direkomendasikan oleh kerangka yang saya pilih, dan meskipun saya menyukai ide lapisan tambahan yang disediakan ORM, saya mulai menyadari apa artinya ini. Itu berarti saya tidak lagi bekerja dengan database saya (mysql) dan semua fitur spesifik mysql hilang, keluar jendela, seolah-olah tidak ada.

Gagasan yang dimiliki ORM adalah bahwa ia mencoba membantu saya dengan membuat semua database agnostik. Ini kedengarannya hebat, tetapi sering kali ada alasan mengapa saya memilih sistem basis data tertentu. Tetapi dengan pergi rute agnostik database, ORM mengambil common denominator terendah, yang berarti saya berakhir dengan set fitur terkecil (yang didukung oleh semua database).

Bagaimana jika saya tahu bahwa untuk jangka panjang saya tidak akan mengganti basis data yang mendasarinya? Mengapa tidak mengakses fitur khusus basis data juga?


2
+1: Sangat menarik. Saya biasanya menjadi pendukung ORM, tetapi saya biasanya menganggap RDBMS sama (yang baru-baru ini saya anggap salah).
Steven Evers

Sepertinya Anda hanya ingin konfirmasi pendapat Anda sendiri; sebuah blog mungkin lebih cocok untukmu daripada situs tanya jawab.

Anda mungkin tidak perlu membutuhkan lebih dari yang disediakan ORM. Anda hanya ingin menyimpan data objek Anda dalam database dan itulah yang akan dilakukan ORM. Anda seharusnya tidak memerlukan 'fitur' lainnya.
CJ7

Jawaban:


14

Saya melihatnya dengan cara yang sama. Abstraksi apa pun yang tidak memungkinkan Anda untuk berada di bawahnya saat diperlukan adalah kejahatan, karena itu menyebabkan semua jenis inversi abstraksi jelek dalam kode Anda.

Di tempat kerja, kami memiliki ORM buatan sendiri yang berfungsi cukup baik, tetapi untuk saat-saat ketika kami membutuhkan sesuatu yang tidak disediakan oleh fitur-fiturnya, ada metode yang mengambil string dan menjatuhkannya langsung ke kueri yang dihasilkannya, memungkinkan untuk penggunaan SQL mentah saat diperlukan.

IMO setiap ORM yang tidak memiliki fitur ini tidak sebanding dengan bit yang dikompilasi darinya.


drops it directly into the query it's generatingKedengarannya menarik. Tahukah Anda berapa lama Anda menulis ORM buatan sendiri ini? Saya ingin melihat sesuatu seperti ini di salah satu ORM open source di luar sana.
jblue

+1. Bekerja dengan aspek terpenting dari aplikasi (data) saya adalah hal terakhir yang ingin saya abstraksi dan kehilangan koneksi.
Fosco

1
Saya suka bisa menyelam di bawah bila perlu, selama menyelam itu melibatkan melintasi pagar metaforis: "Ini naga. Perhatikan langkahmu."
Frank Shearar

1
@Jblue: Tidak tahu. Semuanya ditulis bertahun-tahun yang lalu, jauh sebelum saya diterima. Mereka membuat ORM sebelum ada yang menggunakan istilah itu. Ini biasanya hanya disebut "Model Objek" di basis kode kami.
Mason Wheeler

3
Saya setuju. Untuk hal-hal dasar dan biasa ORM sangat membantu. Tetapi kadang-kadang Anda perlu sedikit lebih dalam, dan jika ORM tidak memberikan kemampuan itu, maka itu satu lagi sumber masalah bagi Anda.
Nikos Steiakakis

14

ORM mengambil penyebut umum terendah

Saya harus tidak setuju dengan pernyataan Anda. Saya akan mengambil nHibernate sebagai contoh. Kerangka kerja ini mendukung banyak basis data, termasuk yang paling populer, terlepas dari versi (dan fitur yang didukung), seperti kebanyakan ORM.

Catatan cepat: Anda hanya menyebutkan abstraksi basis data. Itu salah satu dari banyak manfaat, tetapi saya benar-benar berpikir bahwa fitur berorientasi objek lebih kuat (misalnya: warisan). Dan You design your domain model first...

... Kembali ke abstraksi. Ini bukan penyebut umum terendah. Di nHibernate , Anda memiliki dialek. Ini memungkinkan Anda untuk menggunakan kode yang sama untuk menanyakan berbagai basis data. Dialek menangani manajemen fitur untuk Anda. Pernyataan yang benar adalah itu a given dialect will try to use all the power of a given database system.

Sebagai contoh ambil SqlServer2005dialek bahwa ketika diperkenalkan mengambil keuntungan dari fitur paging SQL Server 2005 baru. Menggunakan dialek itu alih-alih SqlServer2000hanya meningkatkan penampilan Anda.

Tentu saja ada pengecualian, tetapi saya tidak menemukan satu pun dalam beberapa tahun bekerja dengan nHibernate, dan aplikasi saya sangat data centric.


+1 untuk mengadvokasi NHibernate. Sedikit kurva belajar dibandingkan dengan ORM lain, tetapi upaya itu sepadan.
richeym

1
Saya ingin mendengar dari beberapa DBA tentang ini. Di pekerjaan terakhir saya, Hibernate tidak lain adalah masalah (SQL yang dihasilkannya benar-benar menjijikkan.)
Fosco

+1 untuk komentar ini. Itu tepat. Ketika Anda mulai membandingkan kekuatan ORM yang bagus seperti nHibernate (dengan caching, lazy-loading, dll) maka Anda akan melihat mengapa abstraksi ini baik dan mengapa kebutuhan khusus basis data Anda kurang penting.
Chris Holmes

1
Fosco, beri Hibernasi kesempatan lain. Seperti technoloy lainnya, Anda harus memahami apa yang terjadi di dalam, untuk menggunakannya dengan benar.

+1, ORM adalah persimpangan maksimum dari apa yang dapat dilakukan Java dengan apa yang dapat dilakukan oleh driver JDBC tertentu. Anda bebas memilih jumlah investasi yang ingin Anda buat di lapisan kegigihan aplikasi Anda
bobah

5

Idenya rapi, tapi saya belum pernah pindah ke titik untuk menggunakan alat ORM. Hanya saja bukan masalah bagi saya untuk menulis SQL sendiri (atau menangani penyimpanan apa pun yang digunakan). Tapi, saya memiliki kemewahan bekerja pada sejumlah kecil proyek dengan masa pakai produk yang lebih lama, jadi begitu manipulasi kode dan SQL yang dikodekan dengan tangan sudah ada, sudah ada. Plus, Anda jelas dapat menangani setiap query SQL langsung yang Anda butuhkan tanpa harus menyesuaikan proses Anda dengan cara berpikir ORM tool.

Jadi, saya kira pertanyaannya harus sebelum Anda melompat ke satu:

Apakah Anda benar-benar mendapatkan sesuatu dari menggunakannya? Yaitu, apakah Anda menghemat jumlah usaha yang cukup dengan mengimplementasikan alat ORM agar layak digunakan, dan membuatnya layak menambahkan kerumitan ekstra ke sistem Anda? (Ini terutama berlaku untuk aplikasi komersial, di mana 'bagian' tambahan itu sekarang menjadi vektor tambahan untuk masalah dukungan potensial)

Dan kemudian, apakah lapisan abstraksi tambahan akan berdampak negatif pada aplikasi? Apakah akan lebih lambat dari kode SQL tangan, dll.


5

O / RM telah dikritik secara teratur. Ted Neward menyebutnya " Vietnam of Computer Science " beberapa tahun yang lalu. O / RM

dimulai dengan baik, semakin rumit seiring berjalannya waktu, dan tak lama kemudian menjebak penggunanya dalam komitmen yang tidak memiliki titik demarkasi yang jelas, tidak ada kondisi menang yang jelas, dan tidak ada strategi keluar yang jelas.

Kecuali Anda hanya menulis sendiri pemetaan ad-hoc Anda (yang merupakan solusi yang baik dalam banyak kasus, seperti yang telah dikatakan oleh orang lain), Anda dapat melihat alternatif seperti menggunakan database non-relasional. Ada yang mengatakan bahwa database objek benar-benar lebih baik, kata kunci lain yang disebutkan dalam konteks ini adalah LINQ, Ruby, dan Tutorial D. Saya kira, berbeda dengan database yang benar-benar relasional, ada database objek yang benar-benar. Namun dalam praktiknya saya menemukan bahwa pemodelan data konseptual - yaitu untuk mencari tahu, objek dunia nyata yang ingin Anda simpan data, dan bagaimana objek-objek ini berhubungan satu sama lain - lebih penting yang mengutak-atik bagaimana mengekspresikan Anda model konseptual dalam setiap bahasa pemrograman atau basis data.


2
Bagus dibaca di sana. Saya telah datang dalam lingkaran penuh dalam karir dan telah memeluk kembali model relasional dengan kesuksesan penuh.
Jé Queue

2
+1 @Xepoch - Saya baru-baru ini tentang wajah re: ORMs - mengapa SQL ditinggalkan dalam cuaca dingin? Abstraksi, tentu - tetapi ORM tampaknya mempromosikan fobia SQL.
sunwukung

1
@sunwukung, saya tidak selalu setuju, tapi saya sekarang percaya bahwa SQL harus dianggap sebagai lapisan logika kelas 1, bukan hanya sesuatu yang digunakan sebagai protokol kawat.
Jé Queue

3

Apa alternatifnya?

Ini gagasan yang menarik. Dengan mengabstraksi fitur-fitur dari basis data yang mendasarinya, kami pasti kehilangan beberapa fitur dari implementasi basis data tertentu. (Apakah kita harus bergantung pada fitur basis data tertentu atau tidak adalah argumen lain) Saya kira ini bisa diselesaikan dengan ORM spesifik basis data yang memungkinkan Anda untuk mengakses fitur spesifik, tetapi itu mungkin lebih banyak masalah daripada nilainya dan langkah dalam arah yang salah.

Pada akhirnya, Anda harus bertanya pada diri sendiri - apa alternatifnya?

Haruskah kita berhenti menggunakan ORM dan kembali menulis sendiri semua akses basis data? Tentu kami mungkin kehilangan akses ke beberapa fitur basis data melalui ORM, tetapi Anda selalu dapat mengakses mereka yang menggunakan teknik jadul. Pada akhirnya keuntungan yang Anda dapatkan dalam produktivitas benar-benar melebihi kerugiannya.


Saya akan mempertanyakan perlunya menggunakan database rasional sama sekali. Itu menggangguku bahwa orang-orang segera melompat ke RDBMS bahkan jika mereka bukan solusi yang tepat. Database objek, misalnya, memberikan solusi yang sangat elegan untuk banyak masalah. Apakah mereka sempurna? Tidak, tetapi orang jarang repot untuk mengevaluasinya. Ada tren yang mengganggu, "Saya perlu menyimpan data, saya akan menggunakan SQL!"
Matt Olenik

6
@Matt: RDBMSes adalah teknologi yang sangat teruji dan terbukti serta dipahami dengan baik. Ada banyak orang yang berpengalaman dengan mereka, dan sejumlah besar alat pihak ketiga. Dari sudut pandang perusahaan, ada banyak nilai ketika Anda berurusan dengan sesuatu yang sangat berharga seperti data Anda. Pada proyek yang lebih kecil, masih ada nilai untuk memulai proyek (seperti layanan web LAMP) dan memiliki sebagian besar perangkat lunak di sana dan didokumentasikan dengan baik.
David Thornley

3

ORM pada dasarnya berjumlah " Prosedur Tidak Disimpan ". Di sana, saya menciptakan istilah.

Semua yang dilakukan ORM, Anda dapat meniru dengan Tampilan, Pemicu, dan Prosedur yang Disimpan. Mereka membantu mengabstraksi SQL mentah dan menjaga database yang dinormalisasi tetap konsisten. Tapi itu hanya berfungsi dengan baik untuk kasus-kasus sederhana. Jika ada terlalu banyak data mach untuk diproses, mereka bisa menjadi penguras kinerja. (ORM dalam PHP sering mengambil sisi skrip data, karena rantai pembangun SQL tidak dapat mengabstraksikan semuanya.)

Tetapi seperti biasa, itu semua tergantung pada aplikasi dan tugas yang dihadapi.


2
"Prosedur Tidak Disimpan" - istilah yang tepat adalah "Parameterized SQL". Anda hanya menggaruk permukaan apa yang bisa dilakukan ORM dewasa untuk Anda (batching, lazy-loading, dll)
richeym

@richeym: Sebagian besar ORM di PHP tidak menggunakan pernyataan yang disiapkan, atau placeholder yang diparameterisasi. Ini SQL melarikan diri dan penggabungan sepanjang jalan. Tentu saja mereka memberikan keuntungan tingkat yang lebih tinggi daripada pertanyaan SQL manual yang membosankan. Namun pada dasarnya mereka mengambil pemrosesan logika dari database, karenanya "prosedur yang tidak disimpan".
mario

3

Satu hal yang menyakitkan menggunakan ORM adalah bahwa banyak penggemar mereka cenderung mengklaim kita tidak perlu lagi tahu teori SQL dan RDB. Hasilnya bervariasi dari lucu hingga benar-benar bencana. Dan ini terlepas dari jutaan kali pembuatan dan pakar ORM menyatakan bahwa kita harus mengetahui teori SQL dan RDB dengan baik untuk menggunakan dan mengkonfigurasi ORM dengan benar.

Mengapa orang menggunakan alat yang memiliki banyak kegunaan, tetapi tidak semua konteks menjadi magis, peluru perak yang berlaku universal ada di luar jangkauan saya.


1

Tahun lalu saya mengerjakan aplikasi internal yang sering berubah, dan saya sangat senang kami menggunakan ORM. Aplikasi ini adalah aplikasi pendukung untuk tim manajemen perubahan, dan seiring perkembangan proyek yang lebih besar, aplikasi kecil kami mendapatkan persyaratan baru untuk situasi yang tidak ada dan tidak dapat diramalkan beberapa bulan sebelumnya.

Berkat ORM ( Propel , dalam PHP), kami membagi beberapa logika untuk kode, jadi satu fungsi menambahkan bagian "is record valid" dari kueri, yang lain bagian security ("tampilkan catatan ini hanya jika pengguna memiliki kemampuan ini "), ... Jika struktur yang mendasarinya berubah (bidang tambahan yang harus dipertimbangkan untuk" merekam validitas "), kami hanya perlu mengubah satu fungsi, bukan dua puluh klausa SQL.

Kami datang dari situasi di mana semua (well, sebagian besar) klausa SQL disimpan dalam file XML yang terpisah, jadi "perubahan basis data akan mudah ditangani". Percayalah, mereka tidak. Satu bagian sangat mengerikan sehingga saya harus menyerahkannya ke The Daily WTF .

Jika kueri terlalu rumit untuk diungkapkan dengan Kriteria Propel, atau kami memerlukan beberapa fitur khusus vendor (kebanyakan pencarian teks lengkap, karena kami menggunakan MySQL), ini bukan masalah dengan Propel. Anda dapat menambahkan kriteria khusus , atau ketika benar-benar diperlukan, kami menggunakan SQL mentah ( sekarang bahkan lebih mudah digabungkan dengan objek Propel sebenarnya). Anda dapat dengan mudah menambahkan add-on khusus vendor Anda ke kelas yang dihasilkan, sehingga Anda memiliki yang terbaik dari kedua dunia: tidak ada SQL dalam kode aplikasi Anda, tetapi dengan semua kemampuan mesin database Anda.


1

Tetapi intinya adalah Anda bisa memprogram jauh dari basis data, artinya Anda tidak perlu berpikir seperti berada di dalam basis data.

Saya bekerja di C # sekarang dan banyak menggunakan LINQ, jadi banyak dan banyak metode yang lancar. Saya tidak perlu memikirkan bagaimana objek saya disimpan atau ditemukan, atau bahkan disimpan pada level program, dan sangat sedikit pada level layer bisnis.

Cukup sering metode yang disediakan oleh Database Tertentu itu sendiri digunakan dalam Konektor DB, sehingga Anda mendapatkan optimasi tersebut tanpa perlu tahu apa itu.

Anda masih bisa menulis fungsi sisi-DB. Seringkali Anda bisa memetakannya.

Dan di atas semua, pemisahan seperti itu memungkinkan testability dan memaksa Anda (sedikit) untuk menulis kode terstruktur yang lebih baik


2
Sekali lagi, mengapa Anda perlu memprogram jauh dari database? Mengapa tidak menjadikan database sebagai bagian integral dari pengembangan Anda karena Anda telah memilih untuk menggunakannya di tempat pertama. Jika Anda tidak memerlukan RDBMS mengapa mendorong ORM di atasnya?
Jé Queue

1
Itu adalah bagian yang tidak terpisahkan. Database sangat baik dalam memelihara dan menegakkan hubungan dan mengambil data mentah. Namun, hal-hal yang ingin Anda lakukan dengan data ini kemungkinan besar sudah ditangani dalam pembungkus ORM. Dan selain hal-hal penting, mengapa mengeluarkan logika dari lapisan bisnis?
burnt_hand

@burnt_hand - "Tapi intinya adalah Anda bisa memprogram jauh dari basis data, artinya Anda tidak perlu berpikir seperti berada di dalam basis data." Apa keunggulan universal? Saya bisa melihatnya sebagai keuntungan ketika aplikasi Anda hanya mencari cara untuk bertahan objek. Tetapi untuk data relasional, OLTP dan sejenisnya, pemrograman jauh dari basis data adalah salah satu cara untuk mengacaukan waktu Anda sendiri.
luis.espinal

@ luis.espinal - apa artinya mengacaukan waktu Anda? Saya benar-benar ingin tahu. Apakah kamu punya contoh?
burnt_hand

@burnt_hand - sebenarnya saya punya beberapa contoh nyata. Yang terbaru melibatkan model domain yang sangat besar dan sebagai masalah kinerja, proyek harus mengunggah semua pemetaan hibernasi saat start up. Pabrik sesi yang dihasilkan akhirnya memakan hingga 30% dari memori yang digunakan ... hanya untuk binding. Basis kode terlalu berkomitmen sekarang dengan ORM, dan tidak mungkin untuk menulis ulang. Ini sekarang memiliki implikasi aktual karena aplikasi ini mendekati batas fisik pada perangkat keras yang seharusnya dijalankan. Gelandangan.
luis.espinal

1

ORMs dapat memberikan Anda akses ke database tertentu fitur juga, itu tergantung pada ORM yang Anda gunakan dan apa fitur yang menyediakan.

Sebagai contoh, dalam proyek yang sedang saya kerjakan, kami menggunakan Java Persistence API dan Hibernate. Meski begitu, kami menggunakan beberapa fitur khusus basis data, seperti mencari di tabel dengan soundex.

Bagi saya, manfaat utama menggunakan ORM tidak selalu membuat ia menjadi basis data aplikasi agnostik (walaupun itu adalah hal yang baik juga), tetapi saya sebagian besar tidak harus memikirkan bagaimana barang disimpan dan diambil.

Namun , pada titik tertentu Anda kemungkinan besar harus memikirkan hal ini, tergantung pada persyaratan untuk aplikasi Anda. ORM bukanlah sihir.


1

Saya menulis sendiri yang membantu saya memilih dan memasukkan lebih mudah.

Setiap hal tertentu tersedia. Saya hanya perlu menulis kueri sendiri yang dibantu oleh perpustakaan (saya dapat menggunakan '?' Dan params, bukan secara manual memberi nama parameter dan menggunakan .Add)

Saya kira setengah saya mengisap setengah berguna. Saya mendapatkan bantuan di dunia ORM dan melakukan bagian penting di dunia permintaan.


1

Menulis kode untuk menyisipkan dan memilih, memperbarui inline atau dengan procs tersimpan dan memetakannya kembali melalui DAL adalah norma yang lebih lama daripada hanya menguntungkan dalam kasus luar biasa. ORM yang tersedia, basis data dan bahasa pendukung, Anda harus bertanya mengapa Anda tidak menggunakan ORM?

Mereka standar, universal, baik yang ditentukan atau generik. selain itu lebih cepat dan lebih mudah diimplementasikan. Saya telah menggunakan subsonik, linq-to-sql dan framework entitas. Ini memungkinkan pengembang untuk fokus pada logika dan aturan bisnis alih-alih pemetaan basis data.


1
Ada banyak alasan untuk menggunakan, atau TIDAK menggunakan ORM. ORM bukanlah obat mujarab dan sangat sedikit orang yang benar-benar tahu cara menggunakannya secara efektif. Lebih jauh, dalam banyak kasus, logika bisnis sudah tercermin (sebagian) dengan cara yang sangat alami dalam hubungan yang sudah ada dalam RDBMS (ini adalah skenario paling umum yang pernah saya temui, dulu dan sekarang). RDBM yang dirancang dengan baik memiliki fondasi matematika yang kuat, mudah dipahami, dicoba-dan-benar. Tidak semuanya harus dimodelkan dengan RDMB tentu saja, tetapi sama-sama demikian, ORM juga bukan solusi universal.
luis.espinal

1

Dua sen saya (sederhana):

1: Ada ORMS dan ada ORMS. Beberapa ORMS didasarkan pada Rekaman Aktif, yang lain berdasarkan Data Mapper - yang dengan sendirinya merupakan pertimbangan yang relevan, tetapi yang membutuhkan beberapa penyelidikan untuk memahami implikasinya. Secara umum - pengalaman saya di PHP adalah bahwa ORMS mendukung yang pertama, hanya sedikit yang mendukung yang terakhir. ORMs berbasis Rekaman Aktif tampaknya memiliki satu dari dua efek - mereka baik mende-normalkan-kan basis data, atau memanggil sejumlah besar kelas untuk mendukung interaksi objek.

2: Keuntungan ORM berkurang dalam korelasi langsung dengan kompleksitas kueri yang perlu Anda jalankan. Ketika Anda memiliki hubungan sederhana yang bagus - yaitu Pengguna -> Posting, mereka dapat bekerja dengan sangat baik. Ini (IMO) adalah alasan mengapa sebagian besar ORM / kerangka kerja menggunakan contoh-contoh seperti ini. Ketika Anda perlu menjalankan query yang kompleks, jumlah ORMQL yang Anda perlu hasilkan sebanding dengan panjang string dari query SQL biasa - tetapi kurang berkinerja karena grafik objek yang menjalankan query query, jenis yang mengalahkan titik dari abstraksi. Jadi, singkatnya - ORM brilian untuk 30-50% pertama dari tugas basis data Anda - tetapi mengerikan untuk yang terakhir. Saya pikir ini adalah alasan lain mengapa AR sangat lazim.

3: Mengapa bersembunyi dari database? Apakah Anda menggunakan bahasa sisi server untuk abstrak javascript?

Secara pribadi saya mencampur pendekatan-pendekatan itu:

  • gunakan ORM untuk dasar-dasarnya, memuat "pengguna"
  • menggunakan DAO yang berisi beberapa query SQL yang sudah dipanggang (mis. selectLike, selectWhere).
  • memperpanjang DAO jika perlu untuk menambahkan kueri khusus yang lebih spesifik tetapi dapat digunakan kembali
  • Berikan akses basis data sederhana melalui DAO - mis. $ Data = Dao-> kueri (string sql Anda) untuk mengeksekusi satu query.

Setelah mengatakan semua itu, Doctrine 2 akan segera keluar, yang terlihat sangat menarik.


0

Anda dapat menggunakan kerangka kerja SQL mapper seperti myBatis jika Anda ingin memanfaatkan fitur sql.


Itu sebenarnya bukan jawaban untuk pertanyaan jblue tentang manfaat menggunakan mapper seperti itu
Lukas Eder
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.