Serialisasi Java - keuntungan dan kerugian, gunakan atau hindari? [Tutup]

Serialisasi digunakan untuk ketekunan di Jawa. Mungkin oke untuk bertahan beberapa objek menggunakan serialisasi. Tapi, untuk sejumlah besar objek, ORM, Database dll mungkin lebih baik. Tampaknya serialisasi hanya berguna untuk pekerjaan kecil. Mungkin saya salah. Jadi tolong beri tahu saya apa kelebihan serialisasi daripada metode non-serialisasi? Kapan harus digunakan dan kapan harus dihindari?

Pertanyaan ini muncul di benak saya setelah melihat artikel DZone Is Serialization Object Evil?

Dan ini adalah baris yang memunculkan pertanyaan saya:

Jika Anda melihat Java dan objek sesi, serialisasi objek murni digunakan. Dengan asumsi bahwa sesi aplikasi berumur pendek, artinya paling banyak beberapa jam, serialisasi objek sederhana, didukung dengan baik dan dibangun ke dalam konsep sesi Java. Namun, ketika kegigihan data melebihi periode waktu yang lebih lama, mungkin berhari-hari atau berminggu-minggu, dan Anda harus khawatir tentang rilis baru aplikasi, serialisasi dengan cepat menjadi jahat. Seperti diketahui oleh pengembang Java yang baik, jika Anda berencana untuk membuat serial objek, bahkan dalam satu sesi, Anda memerlukan ID serialisasi nyata (serialVersionUID), bukan hanya 1L, dan Anda perlu mengimplementasikan antarmuka Serializable. Namun, sebagian besar pengembang tidak tahu aturan sebenarnya di balik proses deserialisasi Java. Jika objek Anda telah berubah, lebih dari sekadar menambahkan bidang sederhana ke objek, ada kemungkinan bahwa Java tidak dapat melakukan deserialisasi objek dengan benar walaupun ID serialisasi tidak berubah. Tiba-tiba, Anda tidak dapat mengambil data Anda lagi, yang pada dasarnya buruk.

Sekarang, semoga pengembang yang membaca ini mengatakan bahwa mereka tidak akan pernah menulis kode yang akan mengalami masalah ini. Itu mungkin benar, tetapi bagaimana dengan perpustakaan yang Anda gunakan atau pengembang lain yang tidak lagi dipekerjakan oleh perusahaan Anda? Bisakah Anda menjamin bahwa masalah ini tidak akan pernah terjadi? Satu-satunya cara untuk menjamin itu adalah dengan menggunakan metode serialisasi yang berbeda.

Serialisasi sebagian besar digunakan di dua bidang:

• prototyping dari kegigihan

  cukup banyak setiap objek grafik dapat dengan cepat dibuat serializable, untuk pembuktian konsep cepat atau aplikasi cepat dan kotor ini mungkin lebih cepat daripada menyiapkan lapisan ORM nyata atau sistem ketekunan lainnya

• penyimpanan jangka pendek dari objek yang hampir arbitrer:

  Server aplikasi, misalnya, memiliki kecenderungan untuk mempertahankan informasi sesi menggunakan serialisasi. Ini memiliki keuntungan bahwa nilai-nilai dalam sesi bisa hampir semua jenis (asalkan serializable).

Untuk hampir semua kegunaan lain, kelemahan yang Anda (dan artikel) sebutkan terlalu besar: format yang tepat sulit dipertahankan, perubahan kelas dapat dengan mudah membuat data serial Anda tidak dapat dibaca, membaca / menulis data dalam kode non-Jawa hampir mustahil (atau setidaknya jauh lebih sulit dari yang diperlukan).

JAXB dan teknologi serupa menyediakan fungsi serupa dengan biaya rendah yang sama, sekaligus mengurangi beberapa masalah.

Saya menggunakan serialisasi objek untuk memungkinkan analisis post-mortem jika terjadi kesalahan tak terduga dalam produksi. Input ke penghitungan adalah serial untuk file data. Jika kesalahan dilaporkan, program sederhana dapat memuat ulang input dan menjalankan kembali perhitungan dengan debugger terlampir. Atau shell asyik dapat digunakan untuk memuat ulang objek dan memodifikasinya jika diinginkan.

Kami juga menggunakan serialisasi untuk mengirimkan objek Java melalui HTTP ke layanan web. Jauh lebih mudah daripada membuat cerita bersambung dari dan ke teks. Kerugiannya adalah bahwa instalasi klien dan server harus dikerahkan bersama, tapi itu tidak masalah karena kami mengontrol kedua ujungnya.

Apa keuntungan dari serialisasi dibandingkan metode non-serialisasi?

Serialisasi Java memiliki beberapa keunggulan:

• Dibangun ke dalam sistem : Anda tidak perlu bergantung pada alat pihak ketiga, pustaka, atau konfigurasi.

• Relatif mudah dipahami , setidaknya di awal.

• Setiap pengembang tahu itu (atau seharusnya). Terlepas dari apakah dev Jawa menyetujui atau tidak, mereka cenderung akrab dengan serialisasi objek Java.

Dan, tentu saja, ada kerugiannya:

• Mengalir aliran Java standar. Mengalokasikan memori tetapi tidak memanggil konstruktor, jadi bidang sementara tidak diinisialisasi. Bidang diinisialisasi dalam urutan abjad, bukan urutan sumber.

• Tidak begitu efisien dalam hal ruang, tetapi juga tidak mengerikan. Anda mungkin ingin mengompres hasilnya.

• Rapuh kecuali Anda mengambil tindakan pencegahan ketika benda Anda berubah. Dan bahkan saat itu.

Kapan harus digunakan dan kapan harus dihindari?

Gunakan saat :

• Ukuran penyebaran penting. Dibangun ke dalam sistem, jadi 0 byte tambahan.

• Semua aktor akan menggunakan versi yang kompatibel.

• Penyimpanan jangka panjang tidak menjadi masalah.

Hindari ketika :

• Apa pun di atas tidak berlaku.

Serialisasi dan ORM / database adalah hal yang berbeda, meskipun ada beberapa tumpang tindih.

Objek berseri mewakili semua informasi yang diperlukan untuk "mencairkan" objek yang ada dan mengisi kembali datanya. ORM dan basis data tetap menyimpan data ke basis data. Kelas dapat memiliki bidang informasi yang tidak disimpan dalam database oleh ORM, misalnya bidang yang dihitung.

Selain itu, serialisasi dan ORM sedang memecahkan masalah yang berbeda. Serialisasi menyelesaikan masalah mempertahankan grafik objek ke aliran (memori, sistem file, dll). ORM menangani pemetaan potongan informasi ke kolom basis data dan pengambilan dan instantiasi objek, di samping menyediakan basa-basi seperti pencarian dan pemuatan malas.

Gunakan ORM ketika Anda ingin mempertahankan data ke database untuk situasi di mana Anda berurusan dengan sejumlah besar data atau perlu pelaporan, pencarian / pertanyaan, pergudangan, atau hal-hal lain yang dimiliki oleh database. Gunakan serialisasi saat Anda ingin menyimpan representasi struktur data Anda ke disk.

Serialisasi jarang digunakan dalam praktik.

Seperti yang telah disebutkan, kasus penggunaan serialisasi yang paling umum adalah untuk menyimpan objek sebagai gumpalan dalam database sesi. Ini bekerja dengan baik karena dua alasan: sesi cenderung berumur pendek, dan database sesi bagaimana tidak ada pengetahuan tentang cara memetakan objek sewenang-wenang ke model relasional.

Untuk data yang perlu disimpan untuk jangka waktu yang lama (seperti keranjang belanja Amazon) praktik terbaik adalah menyimpan data itu dalam database.

Mekanisme persistensi sesi memastikan bahwa pengguna dengan sesi aktif dikembalikan ke server yang sama. Database sesi hanya diakses ketika server gagal dan pengguna diarahkan ke server baru. Server baru mendeteksi sesi aktif, tetapi tidak menemukannya di memori, sehingga mencoba mengambilnya dari database sesi dalam upaya untuk memberikan pengalaman yang mulus kepada pengguna.

Ada dua masalah dengan pendekatan ini:

Pertama, menyiram data sesi ke database sesi adalah proses yang lambat. Pembilasan data sesi terlalu sering menurunkan kinerja, dan sebagian besar server dikonfigurasikan untuk memerah setiap 30 detik, atau setiap menit, atau lebih lama. Solusi failover "tak terlihat" ini tidak pernah 100% efektif.

Kedua, pengalaman saya adalah sebagian besar klien setuju bahwa memuntahkan pesan kesalahan yang meminta pengguna untuk masuk dan mencoba lagi selama contoh langka bahwa server gagal. Dalam hal ini, kami mematikan basis data sesi sekaligus dan menikmati peningkatan kinerja.

Penggunaan serialisasi lainnya adalah untuk memberikan waktu respons yang lebih cepat dengan menggunakan kerangka kerja seperti Flex yang menggunakan serialisasi dan kompresi grafik objek untuk interaksi server-klien.

Seperti yang telah ditunjukkan oleh orang lain, ada beberapa alasan kreatif dan berguna untuk menggunakan serialisasi, tetapi ini jarang terjadi dalam praktiknya.

Secara historis serialisasi sulit diimplementasikan dengan benar dan andal, membatasi penggunaannya pada sejumlah kecil kasus. Sebagian besar pengembang tidak akan pernah membuat serial objek sendiri, tetapi mungkin bergantung pada kerangka kerja yang melakukannya di belakang layar.

Jawaban singkat untuk "kapan harus menggunakan serialisasi Java" dan "kapan harus menghindari serialisasi Java"

Gunakan serialisasi Java jika

• beberapa kode harus diperlukan
• tidak masalah bahwa data biner tidak dapat dibaca manusia
• mencari data serial tidak diperlukan (permintaan seperti database tidak mungkin)
• antara
  • struktur data serial tidak berubah atau
  • tidak masalah jika data serial yang disimpan tidak dapat dibaca setelah "perubahan struktur data" lagi (yaitu data sesi dalam aplikasi web)

Dalam semua situasi lain "serialisasi Binary Java" buruk

Alternatif

• serialisasi xml
• basis data nosql
• database relasional dengan ORM