Prinsip panduan Anda haruslah Jangan Ulangi Diri Anda Sendiri :
Dalam rekayasa perangkat lunak, Don't Repeat Yourself (DRY) adalah prinsip pengembangan perangkat lunak yang bertujuan mengurangi pengulangan semua jenis informasi, terutama berguna dalam arsitektur multi-tier. Prinsip KERING dinyatakan sebagai "Setiap bagian pengetahuan harus memiliki representasi tunggal, tidak ambigu, otoritatif dalam suatu sistem."
ORM pada dasarnya adalah lapisan tambahan (atau tingkat jika Anda suka), duduk dengan nyaman di antara aplikasi Anda dan penyimpanan data Anda. Kendala Anda harus berada di satu tempat, dan satu tempat saja, baik itu ORM atau penyimpanan data, jika tidak segera Anda akan berakhir dengan mempertahankan versi yang berbeda dari mereka. Anda benar - benar tidak ingin melakukan itu.
Namun, dalam praktiknya, sebagian besar ORM yang layak secara otomatis menghasilkan banyak model Anda dari skema data Anda. Meskipun masih ada duplikasi, kemungkinan neraka pemeliharaan minimal karena kode ORM digandakan dihasilkan mengikuti pola yang sama setiap kali. Akan ideal untuk tidak memiliki kode duplikat, tetapi kendala yang dihasilkan secara otomatis adalah hal terbaik berikutnya.
Selain itu, memiliki kendala di satu tempat tidak selalu berarti Anda harus memiliki semua kendala di tempat yang sama. Beberapa, seperti batasan integritas referensial, mungkin lebih cocok untuk penyimpanan data (tetapi mungkin hilang jika Anda pindah ke penyimpanan data lain), dan beberapa, sebagian besar yang tentang logika bisnis yang kompleks, lebih cocok untuk ORM Anda. Lebih disukai memiliki semua apel Anda di keranjang yang sama, tetapi ...
Kegagalan
Anda menyebutkan ORM gagal. Itu sama sekali tidak relevan dengan pertanyaan Anda, aplikasi Anda harus memikirkan ORM dan penyimpanan data sebagai satu kesatuan. Jika gagal, gagal, melewati ORM untuk berbicara dengan penyimpanan data secara langsung bukanlah ide yang baik.
Memotong ORM untuk hal lain
Juga bukan ide yang bagus. Namun, itu bisa terjadi karena berbagai alasan:
Bagian lawas dari aplikasi yang dibangun sebelum ORM diperkenalkan.
Itu yang sulit, dan persis situasi yang saya hadapi sekarang , maka saya terus-menerus mengulangi "neraka pemeliharaan". Entah Anda mempertahankan bagian-bagian yang bukan ORM, atau Anda menulis ulang untuk menggunakan ORM. Opsi kedua mungkin lebih masuk akal pada awalnya, tetapi ini adalah keputusan yang hanya didasarkan pada apa yang sebenarnya dilakukan bagian aplikasi Anda, dan seberapa berharganya penulisan ulang yang lengkap dalam jangka panjang.
Coba ubah kunci dalam tabel MySQL 2 * 10 ^ 8 yang dirancang dengan buruk (tanpa downtime) dan Anda akan mengerti dari mana saya berasal.
Bagian non-warisan dari aplikasi yang benar-benar perlu berbicara langsung dengan penyimpanan data:
Lebih rumit lagi. ORM adalah alat mewah, dan mereka menangani hampir semua hal, tetapi kadang-kadang mereka hanya menghalangi atau bahkan sama sekali tidak berguna. Kata kunci (buzzphrase betul-betul) adalah ketidakcocokan impedansi objek-relasional , sederhananya itu tidak memungkinkan secara teknis bagi ORM Anda untuk melakukan semua yang dilakukan oleh basis data relasional Anda, dan untuk beberapa hal yang mereka lakukan, ada penalti kinerja yang signifikan.
Komentar
Dari titik integritas data, kendala HARUS pada database, dan HARUS pada aplikasi. Bagaimana jika aplikasi Anda diakses dari web dan aplikasi desktop, atau aplikasi seluler, atau layanan web? - Luiz Damim
Di sinilah menambahkan lapisan tambahan akan sangat membantu, dan jika kita berbicara tentang aplikasi web saya akan menggunakan REST API. Sebuah desain terlalu sederhana untuk ini akan menjadi:
ORM akan berada di antara API dan penyimpanan data, dan segala sesuatu di belakang API (termasuk itu) akan dianggap sebagai entitas tunggal dari berbagai aplikasi.