Teknologi informasi modern memukau dengan kekuatan mereka, mereka kewalahan oleh peluang yang terbuka, mereka tidak dianjurkan oleh kesempurnaan teknis yang melekat di dalamnya, tetapi ada satu titik menggelikan tentang IT yang terus-menerus mematahkan giginya. Tunjukkan data pengguna dari database, dapatkan input darinya, masukkan kembali ke database, tunjukkan hasilnya. Kolom input, tombol, tanda centang, prasasti - akan terlihat sangat rumit sehingga diperlukan untuk membuat konstruksi puzzle seperti kerangka kerja di atas mesin templating di atas kerangka kerja di atas transponder? Dan mengapa, terlepas dari semua upaya luar biasa, kami memiliki fakta bahwa contoh mainan dalam tutorial, tentu saja, dibuat dengan mudah dan menyenangkan, tetapi begitu toolkit menjumpai tugas nyata dari kehidupan nyata ... bagaimana mengatakannya dengan lebih lembut ... dengan meningkatnya kompleksitas tugas yang harus diselesaikan, ada peningkatan non-linearitas yang kuat kesulitan implementasi. Ya, itu akan menjadi pertanyaan tentang sesuatu yang benar-benar membingungkan pada tingkat fisika teoretis atau teknologi ruang angkasa, karena tidak ada yang sama - tombol dan tanda centang. Mengapa omong kosong ini terus meracuni kehidupan warga dan kolektif kerja selama beberapa dekade?
Alasannya, mungkin, seperti biasa, banyak. Mungkin semuanya layak dipertimbangkan dalam satu atau lain cara, tetapi di sini dan sekarang kita akan berbicara tentang tugas Pemetaan Objek-Relasional (ORM), yang selalu di belakang beberapa "tombol dan tanda centang" dalam beberapa bentuk.
Apa yang kita ketahui tentang ORM
- Menyimpan data dalam tabel relasional bukan untuk mengatakan bahwa itu adalah masalah yang sangat sederhana, tetapi secara umum baik ide maupun cara penerapannya cukup jelas dan diteliti dengan baik.
- Dengan pemrograman objek, tidak semuanya begitu baik (ada beberapa pendekatan yang bersaing), tetapi secara umum, dengan penerapan dan penerapan teknologi, semuanya juga kurang lebih jelas.
- Baik itu, dan yang lain - tentang data, penyimpanan dan pemrosesan mereka. Faktanya, tentang hal yang sama.
- Tampaknya logis bagi kita bahwa harus ada jembatan yang sederhana, dapat dipahami, nyaman, dapat diprediksi dan universal antara kedua dunia.
- Dan setiap kali kita menemukan jembatan ini dengan mudah, tetapi kemalangan, kesederhanaannya, kelengkapannya, kenyamanannya, kepastiannya dan universalitasnya tidak bekerja di luar contoh sederhana dari tutorial.
- Semua orang menderita: para pengembang, yang harus melakukan banyak pekerjaan yang sangat membosankan, dan para pengguna yang harus berjuang dengan perangkat lunak yang canggung, dan bisnis, realisasi kebutuhan yang tiba-tiba menjadi panjang dan mahal, dan industri secara keseluruhan tak tertahankan.
- Saya telah melihat banyak ORM yang berbeda, tetapi belum melihat yang baik. Artinya, sesuatu yang, di luar contoh sederhana, tidak berubah menjadi beban dan tempat tidur Procrustean.
Kenapa semuanya begitu aneh
Basis ideologis dari teori dan praktik database relasional adalah predikat kalkulus, yaitu cabang matematika. Sedangkan untuk OOP, basis ideologis serupa kurang ada di sana. Orang dapat mencoba merumuskan ide dasar OOP seperti ini: karena dunia terdiri dari objek, akan lebih mudah untuk memodelkannya, dunia ini, dengan membuat objek di dalam sistem perangkat lunak. Dalam hal ini, dua kesalahan sekaligus. Pertama, dunia itu sendiri tidak terdiri dan tidak pernah terdiri dari objek. Kedua, saya minta maaf, tetapi mengapa program harus mensimulasikan dunia? Yaitu, kita memiliki pernyataan yang secara konsep tidak benar, sempurna dilengkapi dengan pernyataan masalah yang tidak bermakna.
Setiap ORM adalah upaya untuk dengan jelas meregangkan korespondensi yang disatukan antara, pada kenyataannya, cabang matematika dan serangkaian praktik yang longgar, berdasarkan pertimbangan kenyamanan, pendekatan yang ditetapkan secara historis, dan juga sering pada legenda, pendapat otoritas, dan hanya kesalahpahaman. In vitro itu bisa dibuat untuk bekerja, tetapi in vivo itu ditakdirkan untuk terlihat menyedihkan dan membawa lebih banyak kesedihan daripada sukacita.
Pada keniscayaan orientasi objek
Namun demikian, kebutuhan akan orientasi objek dari perangkat lunak kami adalah kenyataan yang tidak dapat dihindari. Keniscayaan ini didasarkan terutama pada kenyataan bahwa beroperasi dengan objek adalah esensi dan fondasi dari setiap kegiatan kita. Dunia itu sendiri tidak terdiri dari objek, tetapi untuk memahami sesuatu di dunia ini dan melakukan sesuatu dengan dunia ini, kita sendiri menyatakan bagian-bagiannya sebagai objek, memanggil mereka nama, mencoba memahami perilaku mereka, berlaku untuk Usahanya untuk mendapatkan hasil yang diinginkan. Ini adalah cara kami berfungsi, dan tidak mungkin untuk meninggalkannya, dan itu tidak perlu. Segala sesuatu adalah objek, bukan karena itu benar-benar, tetapi karena kita tidak dapat melakukan sebaliknya. Sesuatu yang sama sekali tidak dapat menjadi objek terletak sepenuhnya di luar batas kemampuan kita untuk memahami dan tidak dapat berfungsi sebagai subjek dari upaya kita.
Sekalipun program ditulis tanpa menggunakan teknik OOP, program itu pasti mengandung objek (dalam arti luas), dengan memanipulasi pengembang yang memecahkan masalahnya - variabel, tipe data, operator, algoritma, konstruksi sintaksis, fungsi, modul. Dari sudut pandang pengguna, program ini juga memiliki serangkaian objek yang berinteraksi - tombol, label, bidang input, halaman, situs, dan seluruh sistem.
Apa yang kami simpan di basis data kami
Seperti disebutkan di atas, basis data relasional didasarkan pada predikat kalkulus. Predikat adalah fakta yang dirumuskan dan, dalam kasus kami, disimpan pada media. Untuk jaga-jaga, saya perhatikan bahwa basis data relasional tidak hanya dan tidak begitu banyak tentang hubungan antara tabel dengan kunci asing. Dalam terminologi yang tepat, hubungan adalah apa yang kita sebut tabel. Artinya, bahkan jika database Anda hanya memiliki satu tabel dengan dua kolom (misalnya, nama dan nomor telepon), Anda sudah memiliki database relasional yang menetapkan hubungan antara dua set, dalam hal ini, set nama dan nomor telepon.
Database relasional tidak menyimpan objek, tetapi menyimpan fakta. Fakta-fakta yang tersimpan, tentu saja, memiliki objek ("tentang fakta apa ini?"), Dan ketika kita mencoba mengajarkan sistem untuk menjawab pertanyaan ini, kita memiliki entitas, yaitu objek yang terkait dengan fakta. Jika Anda bekerja dengan benar, struktur markas kami lahir dari serangkaian jawaban untuk pertanyaan “fakta apa yang ingin kami simpan?”, Dan hanya pada tahap berikutnya kami mendapatkan sesuatu yang menyerupai objek yang memberikan fakta pada objektivitas. Anda dapat, tentu saja, mendesain "dari objek", tetapi saya tidak akan merekomendasikan melakukannya kecuali dalam pekerjaan laboratorium pada mata pelajaran yang tidak secara langsung terkait dengan desain database. Bahaya kesalahan perhitungan arsitektur yang berat terlalu besar. Selain itu, setidaknya tidak nyaman.
Penyimpangan kecil tentang database objek. Pikiran yang sangat sederhana: jika kita bosan dengan masalah ORM, maka mungkin kita harus melakukan sesuatu dengan bagian yang "R"? Biarkan database kami tidak menjadi monster relasional yang tangguh dan menuntut, tetapi sesuatu yang modis yang dirancang khusus untuk menyimpan objek. Beberapa jenis skema NoSQL-base, misalnya. Tetapi pada akhirnya tiba-tiba ternyata ORM seperti NoSQL lebih canggung dan tidak alami daripada SQL-lama yang baik. Bagaimanapun, kita dapat memiliki dan dengan senang hati untuk mengoperasikan DBMS bebas-sirkuit, tetapi tidak ada data bebas-sirkuit di alam. Tidak ada yang lebih tak berdaya, tidak bertanggung jawab, dan tidak bermoral selain ORM untuk basis data tanpa sirkuit.
ORM bagus
ORM yang baik adalah ORM yang hilang. Baik, serius. Lihatlah salah satu sistem ORM Anda dan jujur mencoba menjawab pertanyaan Anda: apa manfaat dari monster ini? Apa alasan penggunaannya kecuali untuk janji-janji kebahagiaan yang tidak terpenuhi dan berulang kali berprasangka orang yang didiskreditkan? Tentu saja, ada beberapa hal berguna yang berguna, tetapi apa yang mereka hadapi dengan latar belakang deformasi arsitektur yang diperkenalkan dan masalah kinerja yang terus-menerus muncul tiba-tiba?
Sebagai aturan, API basis data “tingkat rendah” sederhana, nyaman, lengkap dan konsisten. Biasanya cukup jari untuk mendaftar semua fitur. Untuk mempelajarinya bukan berita dewa tugas apa.
Saya akan mencoba untuk membuat serangkaian prinsip arsitektur yang memungkinkan Anda untuk memetakan objek ke database tanpa menggunakan ORM:
- Kami menyimpan fakta, beroperasi pada objek. Ingatlah bahwa basis data menyimpan fakta, dan model objek yang terlibat dalam pemrosesan data adalah proyeksi kumpulan fakta dari berbagai sudut pandang. Misalnya, untuk contoh yang diberikan dengan nama dan nomor telepon, kita dapat memiliki kelas Abonent, yang beberapa nomornya dapat disimpan, dan juga kelas PhoneNumber, yang beberapa pelanggannya dapat diatur (jangan lupa bahwa selain nomor ponsel pribadi, kita memiliki di mana masih ada apartemen dan telepon kantor). Dan tabel dalam database hanyalah salah satu yang mendefinisikan hubungan banyak-ke-banyak antara banyak nama dan nomor telepon. Hanya dua proyeksi berbeda. Omong-omong, pendekatan ini biasanya berskala pada kasus-kasus yang jauh lebih kompleks, memungkinkan Anda untuk memiliki kelas yang sangat berguna dalam sistem seperti, misalnya, "penjualan rata-rata untuk periode tertentu sesuai dengan kombinasi kriteria yang diberikan."
- Fakta diproyeksikan menjadi objek dan sebaliknya melalui API berorientasi masalah. Tanpa menerapkan solusi yang mengaku universal. Jika Anda masih tidak tahu cara membuat API yang nyaman, maka pelajari caranya. Dan yang penting, ajari diri Anda untuk mendokumentasikannya segera.
- Pesan di atas semuanya. Jika Anda menggunakan versi klasik dari DBMS dengan skema data yang kaku, maka skema ini dengan sendirinya mengatur pekerjaan dengan data. Struktur ekstra yang disandikan oleh struktur objek hanya mubazir. Jika Anda menggunakan DBMS bebas skematis, maka tentu saja Anda harus melakukan upaya untuk memastikan bahwa database Anda tidak berubah menjadi tumpukan sampah karena fakta bahwa pengembang yang berbeda memiliki ide yang berbeda tentang apa yang disimpan.
- Independensi DBMS (jika perlu). Jika properti ORM yang paling menarik bagi Anda adalah independensi DBMS, maka gunakan alat khusus seperti ODBC, JDBC, ADO, atau jika ini tidak memungkinkan, buat tingkat abstraksi Anda sendiri. Ini tidak sesulit kelihatannya pada awalnya. Anda tidak memerlukan dukungan untuk semua kemampuan dari semua DBMS untuk tugas Anda, bukan?
- Jangan lupa tentang aspek tambahan dari bekerja dengan data. Seperti, misalnya, berbagi akses ke data (yang bisa sangat rumit), pemantauan, replikasi, dan banyak lagi. Tapi di sini saya punya kabar baik untuk Anda: karena dalam ORM favorit Anda, tambahkan. aspek ini masih diterapkan sesuai dengan prinsip "Anda tidak akan menyenangkan semua orang, makan apa yang Anda berikan", penolakan layanan meragukan yang harus Anda tangani lebih dari bekerja sama dengan akhirnya akan terbukti menjadi keputusan yang benar secara strategis.
Total
ORM adalah subjek yang sangat menyakitkan bagi industri kami. Di era ketika kecerdasan buatan awan membajak kuantum blockchain, sebagian besar tenaga kerja sibuk mengacaukan logika bisnis dan antarmuka pengguna ke basis data. Jutaan baris kode mengerikan, memaku dengan mikroskop, rasa sakit dan keputusasaan di mana-mana menyertai proses kreatif ini. Salah satu akar dari keadaan yang menyedihkan ini adalah kesalahpahaman yang sangat kuat bahwa ORM universal pada prinsipnya memungkinkan. Tapi itu tidak mungkin, dan ada alasan mendasar untuk ini, yang tidak bisa dihilangkan. Kesadaran akan fakta ini adalah langkah pertama menuju keluar dari mimpi buruk ini. Ada jalan keluar, ada alternatif, tetapi pertama-tama Anda harus menyadari, merasakan, dan belajar untuk tetap fokus pada perhatian.
PS Saya dengan tulus meminta maaf kepada saudara-saudara dalam profesi yang telah menginvestasikan banyak waktu dan upaya dalam menciptakan banyak yang terbaik di dunia ORM. Aku benar-benar minta maaf