序列化存在若干風險,包括不兼容的更改。如果序列化的類中發生不兼容的更改,那麼即使使用靜態最終的long serialVersionUID字段,我們也不能反序列化它。使用序列化是一個好主意嗎?
那麼,序列化的替代方案是什麼? XML?如果有其他選擇,那麼在現實世界的項目中是否有任何序列化的使用?
序列化存在若干風險,包括不兼容的更改。如果序列化的類中發生不兼容的更改,那麼即使使用靜態最終的long serialVersionUID字段,我們也不能反序列化它。使用序列化是一個好主意嗎?
那麼,序列化的替代方案是什麼? XML?如果有其他選擇,那麼在現實世界的項目中是否有任何序列化的使用?
您似乎將序列化與數據格式混淆 - 最好將它們分開。
有,大致三種系列化:
自動化的,全面的,低層次的 - 因爲它可以作爲一種服務來提供,並需要一些努力來使用,這是有用的。但就其性質而言,它與語言/程序中使用的內部格式密切相關 - 如果這種變化,則反序列化將是「困難的」。典型的例子是由java和python提供的「native」序列化;它對於程序狀態的短期快照很有用。
自動化,受限制,中等級別 - 通常用於通信/互操作。這不會支持一種語言的所有功能,可能只允許保存簡單的數據結構。如果這是足夠的,那麼它是一個有用的中間立場,因爲它可以是自動的,但獨立於語言的內部格式(但不一定是程序的細節)。典型的例子包括協議緩衝區,節儉和json庫(而不是 json本身,這是一種數據格式...);顯然,這對於通信和專門的數據存儲非常有用。
「手工編碼」,高層次 - 這需要更多的工作,並可能會減少儲蓄的信息,但目的在某種程度上獨立於程序中使用的內部格式來提取「重要組成部分」 (或語言)。例子包括docbook或open document(默認情況下,jaxb在提供近似於(1)的支持方面相當不錯,但小心謹慎地接近(3));這對長期數據歸檔很有用,並且通常與「官方」規格相關聯。
與上面分開的是用於編碼序列化數據的數據格式。我相信你可以在XML中實現上述所有功能; json傾向於在(2)中使用。無論如何,回答這個問題 - (1)有你注意到的問題。如果(2)足夠,那麼它是一個簡單的解決方案(但仍存在一些問題:(1)如果程序內的數據結構發生變化);否則你需要做(3)所暗示的額外工作。
在什麼情況下?持久性?網絡?... – Puce 2012-04-15 17:55:25
使用XML只是一種不同的序列化格式。 Java也支持XML序列化(內置) – 2012-04-15 18:53:30
您需要澄清'不兼容'的理解。對象序列化規範的對象版本控制部分指定什麼是和不是兼容的類更改。只要你指定一個固定的'serialVersionUID',它就會比你想像的更容忍類更改。 – EJP 2012-04-16 00:20:53