基于內置BinaryFormatter的.Net序列化有哪些不足？（性能，靈活性，限制）如果可能，請在回答中附上一些代碼。例：序列化的自定義對象必須使用[Serializable]屬性修飾或實現ISerializable接口。不太明顯的例子：匿名類型不能序列化。
3 回答
慕蓋茨4494581
TA貢獻1850條經驗 獲得超11個贊
數據的版本控制通過屬性進行處理。如果您不擔心版本控制，那么這沒問題。如果是的話，這是一個巨大的問題。
屬性方案的麻煩在于，它在許多瑣碎的情況下（例如添加新屬性）都非常流暢，但是當您嘗試執行將兩個枚舉值替換為不同的新枚舉值（或任何其他枚舉值）時，它會很快崩潰長期持久性數據附帶的常見方案數）。
我可以介紹很多麻煩的細節。最后，如果需要的話，編寫自己的序列化程序非常簡單。
holdtom
TA貢獻1805條經驗 獲得超10個贊
我同意最后一個答案。性能相當差。最近，我的編碼團隊完成了將模擬從標準C ++轉換為C ++ / CLI的工作。在C ++中，我們有一個手寫的持久性機制，該機制運行良好。我們決定使用序列化機制，而不是重寫舊的持久性機制。
在內存占用量介于1/2和1 Gig之間的大多數舊模擬中，大多數對象具有指向其他對象的指針，并且在運行時具有1000個對象，在一分鐘之內將保留到大約10到15 Meg的二進制文件。從文件還原是可比較的。
使用相同的數據文件（并排運行），C ++ / CLI的運行性能大約是C ++的兩倍，直到我們進行持久性處理（新版本中的序列化）為止，編寫過程需要3到5分鐘，序列化文件的大小約為10到20。序列化文件的大小約為舊文件的5倍?；旧?，我們看到讀取時間增加了19倍，寫入時間增加了5倍。這是不可接受的，我們正在尋找糾正此問題的方法。
在檢查二進制文件時，我發現了一些問題：1.所有類型的類型和程序集數據均以明文形式編寫。這在空間上是無效的。2.每種類型的每個對象/實例都寫入了膨脹的類型/裝配體信息。我們在手保持機制中所做的一件事是寫出了一個已知的類型表。在發現書面類型時，我們在此表中查找了它的存在。如果不存在，則會使用類型info創建一個條目，并分配一個索引。然后，我們將infor類型作為整數傳遞。（類型，數據，類型，數據）此“技巧”將極大地減少大小。這可能需要兩次處理數據，但是可以開發“即時”流程，從而除了將其添加到表中，推送到數據流之外，
我希望重新實現一些核心序列化以這種方式對其進行優化，但是，可惜這些類都是密封的！我們可能仍未找到捷徑。
- 3 回答
- 0 關注
- 1055 瀏覽
添加回答
舉報
0/150
提交
取消