Apakah ORM Anti-Pola? [Tutup]

Saya melakukan diskusi yang sangat menggairahkan dan interessting dengan seorang rekan tentang ORM dan pro dan kontra. Menurut pendapat saya, ORM hanya berguna dalam kasus yang paling langka. Setidaknya dalam pengalaman saya.

Tetapi saya tidak ingin membuat daftar argumen saya sendiri saat ini. Jadi saya bertanya, apa pendapat Anda tentang ORM? Apa kelebihan dan kekurangannya?

Ada a adalah serangkaian kesulitan konseptual dan teknis yang cukup besar dan beragam ketika mencoba mendekati database relasional dari sudut berorientasi objek. Kesulitan-kesulitan ini secara kolektif dikenal sebagai ketidakcocokan impedansi objek-relasional dan artikel Wikipedia terkait sangat informatif. Artikel mengidentifikasi beberapa, saya tidak melihat cara yang masuk akal untuk menggambarkannya di sini. Hanya untuk memberi Anda ide umum, mereka dikatalogkan sebagai:

• Ketidakcocokan
  • Konsep berorientasi objek
  • Perbedaan tipe data
  • Perbedaan struktural dan integritas
  • Perbedaan manipulatif
  • Perbedaan transaksional
• Memecahkan ketidakcocokan impedansi
  • Minimalisasi
  • Arsitektur alternatif
  • Kompensasi
• Pendapat
• Perbedaan filosofis

Saya pikir jika Anda meluangkan waktu untuk membaca artikel Anda akan memahami bahwa fakta bahwa ORM kadang-kadang digambarkan sebagai anti-pola sebenarnya tidak bisa dihindari. Kedua domain tersebut sangat berbeda sehingga pendekatan apa pun untuk memperlakukan satu sebagai yang lainnya secara default adalah anti-pola, dalam arti bahwa anti-pola adalah pola yang bertentangan dengan filosofi domain.

Tapi saya tidak berpikir istilah itu harus berlaku untuk apa pun yang pada dasarnya bertindak sebagai jembatan antara dua domain yang sangat berbeda. Memberi label suatu pola sebagai anti-pola hanya masuk akal di dalam domainnya. Jadi pertanyaan apakah itu anti-pola atau tidak tidak relevan.

Tetapi apakah ini berguna? Ya ORM adalah salah satu anti-pola yang paling berguna di luar sana. Anda akan mengerti mengapa hanya jika Anda menemukan diri Anda dalam situasi praktis di mana Anda harus bertukar basis data dalam suatu proyek. Atau bahkan meningkatkan ke versi lain dari database yang sama. ORM adalah salah satu dari hal-hal itu, yang hanya Anda pahami sepenuhnya saat Anda benar-benar membutuhkannya.

Tentu saja, karena semuanya bermanfaat, ORM sangat rentan terhadap penyalahgunaan. Jika Anda berpikir itu menggantikan kebutuhan untuk mengetahui segala sesuatu tentang database yang Anda kerjakan, maka itu akan kembali dan menggigit Anda. Keras.

Akhirnya, izinkan saya tanpa malu menyambungkan satu lagi jawaban saya , pada yang terkait "Apakah pola ActiveRecord mengikuti / mendorong prinsip-prinsip desain SOLID?" pertanyaan, yang bagi saya adalah pertanyaan yang jauh lebih relevan daripada "apakah itu anti-pola".

Ini mirip dengan bertanya "apakah bor kekuatan merupakan anti-pola?". ORM mendapatkan tempat yang baik di kotak alat saya, mengurangi kode boilerplate saya dan saya masih dapat menggunakan SQL kustom jika perlu. Jadi jika itu anti-pola, pola mana yang dilawannya?

Jawaban saya adalah tidak, ada banyak ORM dewasa di luar sana yang membuat hidup Anda jauh lebih mudah dan membuat kode Anda lebih mudah dimengerti. Ini berarti Anda tidak perlu memahami SQL, justru sebaliknya.

Saya akan benci untuk menyebut sesuatu sebagai "anti-pola" yang pertama kali disebut pola oleh Martin Fowler dan sejak itu telah dianut di hampir setiap bahasa pemrograman modern. (Lihat artikel Wikipedia di ActiveRecord .)

ORM yang baik dapat menyebabkan kode jauh lebih sedikit (dan jauh lebih sedikit pengulangan) dalam suatu proyek, dan tidak ada yang sangat berkorelasi dengan bug seperti jumlah kode asli.

ORM umumnya dirancang untuk menangani kasus penggunaan yang paling umum untuk bekerja dengan database. Pertanyaan kompleks mungkin masih perlu ditulis secara eksplisit. Tapi saya akan sangat tidak suka menulis pertanyaan eksplisit untuk setiap interaksi basis data. Dalam kebanyakan kasus, itu buang-buang waktu.

Menggunakan ORM alih-alih belajar SQL adalah ide yang sangat buruk. Jika Anda tidak tahu persis jenis SQL yang dihasilkan, jika Anda tidak memahami masalah N + 1 dan bagaimana mengoptimalkannya, maka itu pasti akan menyebabkan lebih banyak kerugian daripada kebaikan. Namun saya merasa bahwa saya jauh lebih produktif menggunakan ORM. Saya lebih suka Rails ActiveRecord, yang tidak mencoba untuk berpura-pura bahwa tidak ada database dan tidak menghalangi Anda jika Anda hanya perlu menulis SQL. Namun saya khawatir beberapa orang mungkin mempercayai idiom yang mereka lihat terlalu dalam, tanpa pemahaman mendalam tentang apa yang mereka lakukan.

Pengalaman saya: Saya menggunakan NHibernate dengan Linq2NHibernate.

Pro:

• Itu menghilangkan "Magic Strings", atau setidaknya menawarkan tempat sekali dan hanya sekali untuk menempatkan mereka
• Ini memungkinkan saya untuk bekerja dalam paradigma OO sepanjang waktu
• Kode lebih mudah dibaca
• Kode yang dibangun di atas lebih mudah untuk diubah
• Ini memungkinkan Anda untuk menukar basis data relasional Anda yang sebenarnya tanpa memelihara 2 repositori terpisah (jarang dilakukan, tetapi itu satu manfaat besar jika Anda membutuhkannya).

Cons:

• Kode lebih sulit untuk ditulis , karena
• Ini bukan abstraksi yang memadai - Anda masih harus akrab dengan apa yang dilakukannya di latar belakang

Saya akan mengatakan bahwa itu tidak memenuhi janji yang kebanyakan orang harapkan pada awalnya. Saya tidak akan menyalahkan seseorang karena mengatakan itu anti-pola. Saya menemukan, dalam kasus saya, bahwa saya masih perlu melakukan tes integrasi terhadap database SQLite untuk memastikan bahwa permintaan Linq2NHibernate saya benar-benar berfungsi. Jadi sungguh, jika Anda melakukan tes integrasi terhadap database relasional nyata, maka hal semacam itu menghilangkan masalah dengan "string ajaib".

Jika saya memulai proyek baru, saya tidak yakin apakah saya akan menggunakan ORM atau tidak. Saya mungkin akan, tetapi saya tidak bisa mengatakan pasti Anda harus. Saya akan mengatakan itu seperti perbedaan antara memilih C ++ atau Java / .NET untuk proyek Anda: apakah Anda akan memerlukan fleksibilitas yang Anda dapatkan dengan bekerja di level yang lebih rendah, atau apakah Anda lebih suka bekerja di level yang lebih tinggi dan (seharusnya) lebih produktif? Jawaban normal adalah bekerja pada level setinggi yang Anda bisa lakukan . Itu biasanya berarti menggunakan ORM.

Kekuatan ORM adalah memungkinkan Anda untuk memodelkan perilaku aplikasi menggunakan teknik berorientasi objek. Di dunia yang direkayasa dengan cermat, Anda memiliki satu lapisan aplikasi di mana bahasa bisnis dengan rapi memenuhi bahasa tim pengembangan. ORM adalah enabler dari itu, jika ORM digunakan secara masuk akal.

Kelemahannya adalah bahwa jumlah orang yang benar-benar benar-benar mendapatkan pemrograman berorientasi objek cukup kecil. Banyak orang menulis spaghetti dan bakso, dengan benda-benda yang sangat berpasangan yang memiliki sedikit perilaku sendiri dan perilaku yang sebenarnya berakhir di kelas "Layanan" dan "Manajer" 8000 yang mengerikan, dan kode itu sering kali berbelit-belit sehingga semua orang takut mengubahnya karena mereka tidak tahu apa efek sampingnya.

Selain itu, banyak orang tidak benar-benar mendapatkan model relasional. ORM tidak akan membantu mereka mendapatkannya, dan itu tidak akan membantu mereka dengan mencabut model relasional. Ini hanya memungkinkan Anda untuk fokus pada lapisan domain Anda sejak dini dan melakukannya tepat sebelum Anda mulai terlalu peduli tentang desain database. Jika diterapkan dengan baik, dengan bantuan alat migrasi skema yang masuk akal, dan ORM dapat membantu Anda mencegah bertambahnya utang kode.

Saya telah membangun aplikasi di mana ORM membuat kode aplikasi sederhana, dapat dibaca, dan dapat diuji, dan memiliki kinerja yang wajar. Saya juga memelihara aplikasi di mana polanya disalahgunakan dan kodenya berbelit-belit, tidak bisa dites, lambat, dan rapuh; ternyata ORM itu sendiri tidak ada hubungannya dengan hal ini, kecuali bahwa alih-alih menulis kode buruk yang memodelkan domain aplikasi dengan buruk, tim insinyur lama menulis kode buruk yang memodelkan domain aplikasi dengan buruk dan kode lapisan layanan buruk yang mengabaikan semua nilai yang ORM mereka bisa berikan kepada mereka.

ORM tidak akan membuat Anda lebih pintar, tetapi di tangan pengembang yang tepat, dapat menghasilkan kode yang lebih mudah dikelola dan berkualitas lebih tinggi.

Mungkin jawabannya terletak pada kebalikan dari pertanyaan Anda: Apakah menyimpan data aplikasi Anda dalam sesuatu yang lain dari database relasional ide yang baik? Masalah apa yang Anda hilangkan, dan masalah apa yang akan Anda temukan? Bisakah Anda hidup tanpa kemampuan untuk dengan mudah mereferensikan data Anda (bergabung) atau dengan cepat menyaring catatan yang Anda inginkan berdasarkan beberapa kriteria? Apakah Anda tidak memerlukan dukungan transaksi yang solid (dengan asumsi alternatif Anda tidak memilikinya)? Tidak semua aplikasi membutuhkan penyimpanan data yang selalu konsisten dan lengkap.

Saya pikir anti-pola nyata di sini mungkin menggunakan DB relasional ketika Anda tidak membutuhkannya. Jika Anda membutuhkannya, maka Anda membutuhkan ORM, dan itu jelas bukan anti-pola.

ORM adalah alat. Seperti semua alat, ketika digunakan dengan tepat, mereka bekerja dengan sangat baik. Ketika digunakan secara tidak tepat, perlu palu yang lebih besar dan beberapa lakban.

Dalam kasus proyek saat ini yang sedang saya kerjakan, itu akan dikelola oleh non-pengembang (insinyur mesin, tepatnya) dan jadi itu harus sederhana dan mudah diketahui. Butuh beberapa tahun sebelum grup ini memiliki anggaran untuk merekrut pengembang (menganggap Presiden berikutnya tidak menghapus agen yang terlibat), sehingga kemampuan pemeliharaan di masa depan merupakan faktor utama dalam pertimbangan kami.