Bagaimana Hibernasi Hampir Menghancurkan Karir Saya

Bayangkan Anda adalah seorang pengembang Java, dan Anda akan memulai proyek besar berikutnya. Anda perlu membuat keputusan mendasar yang akan melekat pada Anda selama sisa proyek. Anda ingin memilih abstraksi berorientasi objek terbaik dari model data fleksibel Anda karena Anda tidak ingin berurusan dengan SQL biasa. Anda ingin mendukung semua jenis data, dan idealnya, mendukung semua jenis database.

Jawaban yang jelas adalah dengan hanya menggunakan Hibernate , bukan? 90% pengembang Java akan setuju dengan Anda, tetapi apakah itu membuat keputusan yang tepat?

Mari kita lihat apa yang bisa salah jika Anda menggunakan Hibernate secara membabi buta hanya karena itu adalah standar yang diterima.

Pertimbangkan Monica, seorang pengembang Java. Monica baru-baru ini dipromosikan menjadi arsitek dan sekarang bertanggung jawab untuk meletakkan tumpukan teknologi untuk produk baru di perusahaannya. Dia tahu bahwa di dunia Java hanya ada satu alat yang bagus untuk menangani komunikasi basis data: Hibernate . Hibernate adalah standar JPA yang terkenal dan didukung. Namun, itu selalu merupakan ide yang baik untuk memeriksa beberapa hal sebelum memulai sebuah proyek. Untungnya, rekannya, Ben, mengenal pria yang tepat.

Hibernasi Kedengarannya Seperti Peluru Perak

Ben - Halo Monica, saya ingin memperkenalkan John. Dia ahli Hibernate , dan dia akan membantu Anda.

Monica - Hei John, senang Anda menemukan waktu untuk saya. Jadi, kami sedang membangun Next Big Thing kami, Anda tahu. Kami berencana untuk menjadi Facebook atau Google berikutnya. Hari-hari sibuk. Ini akan menjadi besar. Benar-benar fantastis! Semua orang sangat bersemangat! Saya telah dipromosikan menjadi arsitek, jadi sekarang saya harus memilih tumpukan yang akan kita gunakan. Satu-satunya bagian yang hilang adalah ketekunan ...

John - Hibernasi !

Monika - Ya! Tepat! Hanya apa yang saya pikirkan! Sepertinya ini pasangan yang sempurna dan nyata bagi kami. Solusi perusahaan sejati untuk masalah perusahaan sejati, terbukti oleh pasar dan dengan sejarah panjang. Saya telah mendengar begitu banyak pengalaman positif dengannya. Namun, saya memiliki masalah dengan salah satu rekan tim kami; dia sangat menentangnya. Dia tahu banyak tentang database, dan dia takut menambahkan lapisan lain antara aplikasi kita dan database. Dia sangat cerdas, dan saya membutuhkan beberapa argumen yang sangat bagus untuk meyakinkannya bahwa ini adalah keputusan yang baik. Bisakah Anda membantu saya dengan itu?

John - Tentu saja! Saya akan senang. Hibernate memang merupakan alat yang luar biasa. Ini banyak digunakan dalam solusi perusahaan besar dan nyata, seperti bank. Anda tidak bisa salah dengan itu. Pikirkan ketekunan: Pilih Hibernate . Jika Anda menulis dalam Java, ini benar-benar pilihan yang tepat, ditambah Anda memiliki port untuk bahasa lain. Lihat berapa banyak deskripsi pekerjaan yang membutuhkannya!

Monica - Saya sangat setuju! Saya memiliki perasaan yang sama tentang hal itu. Dalam proyek sebelumnya, kami menggunakan sebagian besar SQL melalui JDBC lama. Konyol! Aku tahu! Tapi, inilah masalahnya: Kami memiliki orang-orang SQL yang sangat pintar dalam tim dan ketika mereka melihat SQL yang dihasilkan oleh Hibernate , mereka menjadi gugup. Tampaknya jelek dan tidak terbaca; apakah ini akan menjadi masalah di masa depan?

John - Lihat. Orang-orang DBA memiliki perspektif yang berbeda. Mereka takut dengan Hibernate karena sepertinya menggantikan peran mereka dalam proyek tersebut. Selain itu, database memiliki pengoptimal kueri bawaan sehingga Anda tidak perlu khawatir akan tampilan kueri tersebut. Basis data akan mengoptimalkannya untuk Anda. Ini semua tentang perkembangan pesat, yang tidak bisa dilakukan SQL.

Monica - Benarkah?! Tidak lagi berurusan dengan SQL? Luar biasa! Terakhir kali DBA menghabiskan waktu berminggu-minggu mencoba mengoptimalkan beberapa kueri. Minggu! Oh, saya merasa sangat malu mengatakan ini kepada Anda, tetapi apakah Anda tahu bahwa kami menggunakan ... prosedur tersimpan (tertawa). Oh, itu sangat kacau. Dapatkah Anda percaya bahwa proyek ini masih menggunakannya? Saya merasa sangat kasihan pada orang-orang di luar sana. Mereka masih harus menulis kode yang membosankan ini berulang-ulang. Saya ingin tahu apakah ini masih proyek Java atau SQL?

John - Itulah perbedaan antara pendekatan berorientasi objek dan pendekatan relasional. Ini yang disebut ketidakcocokan impedansi berorientasi objek. Hibernasi dapat menutup celah ini. Pengembang dapat fokus membangun logika bisnis. Fitur push membuat pemangku kepentingan dan seluruh manajemen senang. Lakukan hal-hal yang paling penting: Bisnis! Banyak kode boilerplate akan hilang, dan Anda akan memiliki koneksi magis, tidak terlihat, tetapi dapat diandalkan, antara logika dan data.

Monica - Gotong royong. Sinergi penuh. Seperti database adalah bagian dari bahasa sejak awal. Saya sangat senang saya bisa menjadi pemimpin lompatan keyakinan teknologi ini. Ini seperti kecepatan warp dalam perjalanan perangkat lunak.

John - Ya! Anda sudah mendapatkannya!

Monica - Astaga, aku sangat bersemangat! Terima kasih, John! Saya siap!

Rasa Sakit Tumbuh Dengan Solusi Tidak Fleksibel

Monica - Hei John, ingat proyek yang kita bicarakan tahun lalu?

John - Tentu. Bagaimana kabarmu?

Monica - Kami akan segera produksi. Semuanya baik-baik saja, tetapi beberapa pertanyaan telah muncul.

John - Tentu, pukul aku.

Monica - Nah, kita tidak bisa lagi membuat skema database kita dari awal. Apa cara terbaik untuk mendukung perubahan skema tanpa kehilangan data?

John - Pertama, Hibernate tidak dimaksudkan untuk digunakan sebagai alat migrasi produksi. Gunakan sesuatu seperti FlywayDB atau Liquibase. Ini cukup sederhana. Anda menuliskan skrip migrasi, lalu memperbarui model entitas bersama dengan pemetaan Hibernate , sehingga tetap sinkron dengan struktur database yang sebenarnya.

Monica - Hmm, begitu. Kami hanya menggunakan migrasi SQL biasa di proyek sebelumnya.

John - Tidak apa-apa juga. Selama Anda menjaga model dan skema entitas tetap sinkron, lakukan sesuka Anda.

Monica - saya melihat. Ada hal lain. Kami selalu berjuang dengan masalah malas/bersemangat mengambil. Pada satu titik, kami memutuskan untuk melakukan semuanya dengan penuh semangat, tetapi tampaknya kurang optimal, dan selain itu, terkadang beberapa bidang tidak dapat diakses karena tidak ada sesi, atau semacamnya. Apakah itu normal?

John - Anda perlu mempelajari lebih lanjut tentang Hibernate . Pemetaan dari database tidak mudah. Pada dasarnya, ada banyak cara untuk melakukannya. Anda hanya perlu memilih cara yang cocok untuk Anda. Pengambilan malas memberi Anda kemampuan untuk memuat objek tersebut sesuai permintaan, tetapi Anda harus beroperasi dalam sesi aktif.

Monica - Kami masih kesulitan dengan mesin basis data mana yang akan digunakan untuk penerapan akhir. Saya pikir Hibernate portabel, tetapi kami memiliki beberapa kueri asli yang menggunakan beberapa keajaiban MS SQL, dan kami sebenarnya ingin menggunakan MySQL dalam produksi.

John - Hibernate memberi Anda fleksibilitas selama Anda menggunakan kriteria terpisah atau HQL; setiap kueri asli hanya akan mengikat solusi Anda ke database.

Monica - Sepertinya kita harus tetap menggunakan MS SQL. Pertanyaan terakhir: Rekan satu tim saya mengatakan bahwa tidak ada kata kunci "batas" di HQL. Saya pikir dia bercanda, tetapi saya juga tidak dapat menemukannya. Maaf untuk pertanyaan bodoh…

John - Memang, tidak ada kata kunci "batas" di HQL. Anda dapat mengontrol ini melalui objek kueri karena ini khusus untuk vendor basis data.

Monica - Tampaknya aneh bahwa semua elemen lain ada di HQL. Sudahlah. Terima kasih atas waktunya!

Kami Sekarang Meretas Solusi Bersama di SQL Lagi

Monica - John, pada awalnya kami tidak akan berurusan dengan SQL, tetapi sekarang sepertinya kami harus melakukannya. Kebutuhan kita tumbuh, dan sepertinya tidak ada jalan lain untuk itu. Rasanya salah, tapi kami mulai menggunakan SQL lagi setiap hari.

John - Yah, itu tidak salah. Anda tidak harus fokus pada database di awal. Namun, seiring perkembangan proyek, ada baiknya menggunakan SQL dan mengerjakan optimasi kinerja.

Monica - Terkadang kita menghabiskan waktu berhari-hari untuk mencari kesalahan. Sepertinya kita harus menganalisis SQL yang dihasilkan Hibernate karena kita tidak tahu mengapa itu tidak berfungsi seperti yang diharapkan dan menghasilkan hasil yang tidak terduga. Kami menemukan beberapa masalah yang terkenal di pelacak bug Hibernate . Selain itu, sulit untuk menulis migrasi yang tepat sambil menjaga model entitas tetap sinkron. Ini memakan waktu karena kita perlu belajar banyak tentang internal Hibernate dan memprediksi cara kerjanya.

John - Selalu ada kurva belajar. Anda tidak perlu banyak menulis, tetapi Anda perlu tahu cara kerjanya.

Monica - Bekerja dengan kumpulan data yang lebih besar juga menjengkelkan. Baru-baru ini, kami melakukan impor besar-besaran ke database, dan itu sangat lambat. Kemudian kami menemukan bahwa kami harus menghapus sesi untuk membuatnya lebih cepat. Meski begitu, ini masih jauh lebih lambat, jadi kami memutuskan untuk menulis ulang sebagai pernyataan SQL biasa. Yang lucu adalah menulis SQL biasa sebenarnya adalah cara tercepat untuk melakukannya, jadi kami memutuskan untuk melakukannya sebagai opsi terakhir kami.

John - Impor bukanlah proses berorientasi objek. Hibernate berfokus pada desain berorientasi objek. Ingatlah bahwa Anda selalu dapat menggunakan kueri asli.

Monica - Bisakah Anda membantu saya memahami cara kerja cache Hibernate ? Saya tidak mengerti. Ada beberapa cache tingkat pertama/kedua. Apa ini semua tentang?

John - Tentu. Ini disebut cache tingkat transaksi dari data persisten. Dimungkinkan untuk mengonfigurasi cluster atau cache level JVM berdasarkan kelas demi kelas dan koleksi demi koleksi. Anda bahkan dapat memasang cache yang berkerumun. Tetapi ingat bahwa cache tidak mengetahui perubahan apa pun yang dilakukan pada penyimpanan persisten oleh aplikasi lain. Namun, mereka dapat dikonfigurasi untuk menghapus data cache yang kedaluwarsa secara teratur.

Monica - Maaf, kurasa hariku buruk. Bisakah Anda menjelaskan ini sedikit lagi?

John - Tentu. Setiap kali Anda melewatkan objek untuk save , update , saveOrUpdate , atau ambil melalui load , get , list , iterate atau scroll , objek itu ditambahkan ke cache internal sesi. Anda juga dapat menghapus objek dan koleksinya dari cache tingkat pertama.

monica - eh…

John - Selain itu, Anda dapat mengontrol mode cache. Anda dapat menggunakan mode normal untuk membaca dan menulis item ke cache tingkat kedua. Gunakan mode get untuk membaca dari level kedua tetapi Anda tidak dapat menulis kembali. Gunakan put , yang sama dengan get tetapi Anda tidak dapat membaca dari level kedua. Anda juga dapat menggunakan mode refresh , yang akan menulis ke level kedua, tetapi tidak membacanya dan mengabaikan properti use minimal puts , memaksa refresh cache level kedua untuk semua item yang dibaca dari database.

Monica - saya melihat. Oke. Biarkan aku memikirkan ini. Oh, sudah larut, aku harus pergi. Terima kasih atas waktunya!

John - Sama-sama!

Menyerah Pada Hibernasi

Monica - John, saya pikir kita sedang memasuki era baru pengembangan perangkat lunak. Saya pikir kami melakukan lompatan satu tahun cahaya. Tapi, setelah empat tahun, sepertinya kita masih menghadapi semua masalah yang sama, hanya dari sudut yang berbeda. Saya harus belajar arsitektur Hibernate , konfigurasi, logging, strategi penamaan, tuplizer, penyelesai nama entitas, generator pengidentifikasi yang ditingkatkan, pengoptimalan generator pengidentifikasi, subkelas serikat pekerja, markup XDoclet, asosiasi dua arah dengan koleksi yang diindeks, asosiasi ternary, idbag, mencampur polimorfisme implisit dengan pemetaan warisan lainnya, mereplikasi objek antara dua penyimpanan data yang berbeda, objek terpisah dan versi otomatis, mode pelepasan koneksi, antarmuka sesi stateless, taksonomi persistensi pengumpulan, tingkat cache, pengambilan malas atau bersemangat dan banyak lagi. Bahkan dengan semua yang aku tahu, sepertinya kita gagal total. Ini adalah kegagalan perangkat lunak! Kegagalan akhir! Bencana! Armagedon!

John - Tunggu! Apa yang terjadi?

Monica - Kami telah mencapai jalan buntu. Kinerja aplikasi kami sangat lambat! Untuk mendapatkan laporan, kita harus menunggu dua hari! Dua hari untuk benar-benar menghasilkan dasbor untuk pelanggan. Artinya setiap hari kita harus meningkatkan ekor perhitungan kita, sementara dashboard kita semakin ketinggalan zaman. Pakar DBA kami telah bekerja selama dua bulan untuk mengoptimalkan beberapa kueri, sementara struktur basis data kami berantakan total. Ada pengembang yang mendukungnya, tetapi masalahnya adalah DBA berpikir dalam SQL, dan pengembang menghabiskan waktu berhari-hari untuk menerjemahkan ini ke dalam kriteria terpisah atau format HQL. Kami mencoba menggunakan SQL asli sebanyak mungkin karena kinerja sangat penting saat ini. Bagaimanapun, kami tidak bisa berbuat banyak karena skema database sepertinya salah. Itu terasa benar dari perspektif berorientasi objek, tetapi tampaknya konyol dari perspektif relasional. Saya bertanya pada diri sendiri: Bagaimana ini bisa terjadi? Pengembang memberi tahu kami bahwa mengubah struktur entitas akan menjadi upaya besar-besaran, jadi kami tidak mampu melakukannya. Saya ingat di proyek sebelumnya itu berantakan, tetapi kami tidak pernah berakhir pada titik kritis seperti itu. Kami dapat menulis aplikasi yang sama sekali berbeda untuk bekerja dengan data. Sekarang, sangat berisiko untuk memodifikasi tabel yang dihasilkan karena sangat sulit untuk memastikan model entitas akan selalu berperilaku dengan benar. Dan ini bahkan bukan bagian terburuknya! Untuk meningkatkan kinerja, kita harus memecahkan tidak hanya masalah database, tetapi juga masalah dengan seluruh lapisan antara database kita dan aplikasi. Ini luar biasa! Kami memiliki orang-orang baru ini, Anda tahu, konsultan. Mereka mencoba mengekstrak data, memasukkannya ke dalam beberapa penyimpanan lain dan kemudian melakukan perhitungan dari luar. Ini semua memakan terlalu banyak waktu!

John - Saya tidak tahu harus berkata apa.

Monica - Anda melihat John; Saya tidak ingin menyalahkan Anda. Saya memilih Hibernate untuk menyelesaikan semua masalah ini, tetapi sekarang saya telah belajar bahwa itu bukan peluru perak. Kerusakan telah terjadi, dan itu tidak dapat diubah. Sebenarnya, saya ingin menanyakan sesuatu kepada Anda: Saya menghabiskan empat tahun terakhir karir saya berurusan dengan hal-hal Hibernate . Sepertinya saya tidak memiliki masa depan di perusahaan saya saat ini. Bisakah kamu membantuku?

Jadi Apa Pelajarannya?

John - Hei, Peter, izinkan saya memperkenalkan Monica.

Peter - Hei, Monica! Kami sedang membangun hal besar berikutnya yang baru, Anda tahu. Ini akan menjadi besar! Kami ingin menjadi seperti Uber! Apakah Anda tahu mungkin bagaimana ketekunan ...

Monica - Bukan Hibernasi !

Bungkus

Monica adalah ahli Hibernasi . Namun, Hibernate dalam hal ini adalah keputusan yang salah. Saat dia menemukan bahwa solusinya berubah menjadi masalah yang lebih besar daripada yang asli, itu adalah ancaman terbesar bagi keseluruhan proyek.

Data adalah tujuan utama dari aplikasi dan, suka atau tidak, mempengaruhi seluruh arsitektur. Seperti yang kita pelajari dari cerita, jangan gunakan Hibernate hanya karena aplikasi Java Anda menggunakan database atau karena bukti sosial. Pilih solusi yang mencakup fleksibilitas. Ada banyak pilihan untuk pembungkus JDBC yang kuat, seperti JdbcTemplate atau Pembungkus JDBC Lancar. Atau, ada solusi kuat lainnya, seperti jOOQ.