我正在開發一個主從風格的應用程序。主應用程序將發送狀態數據給從站以處理並以某種恆定速率顯示。狀態數據被包含到包含許多字段的單個類中。這些字段類型由基元，類，接口，接口列表等組成。所有類型都是BCL或自定義類型，因此可以根據需要修改自定義類型。主應用程序和從應用程序都將是.NET 4.0。我不關心序列化版本控制，因爲主應用程序和從應用程序將作爲一對交付。我應該在.NET 4.0中使用BinaryFormatter進行簡單序列化嗎？
我需要一個「快速」的方式來序列化主設備上的狀態數據並在從設備上反序列化它。當我說「快」時，我更多地談論開發時間（但如果解決方案很糟糕，處理時間可能是一個因素）。但是，主站和從站將通過廣域網分佈，所以一定程度的緊湊性也會很好。
對於快速解決方案，我目前正在考慮簡單地使用BinaryFormatter，然後用GZipStream壓縮流。這是.NET 4.0的方式嗎？
如果開發速度是關鍵（特別是因爲你有接口等，你需要適當地配置一些序列化器），那麼也許。不過，別忘了標記任何事件：
[field:NonSerialized]
在所有其他措施（CPU性能，帶寬，健壯性你的版本，互操作性，維護成本等），我會選擇其他格式:)
這裏是異形的選擇：
Performance Tests of Serializations used by WCF Bindings
也許不是一個驚喜（因爲我寫的），但我的偏向protobuf網...
用'[NonSerialized]'標記事件的好處。我沒有想到這一點。 – dewald 2011-03-12 20:31:38
protobuf-net的性能測試非常令人印象深刻。你的圖書館會爲我的案件工作嗎？我必須序列化接口和接口列表。其中一些接口代表不可變對象;即它們只有getter屬性，而實現類具有私有setter。 – dewald 2011-03-13 00:06:55
@dewald直到大約一個星期前，它會與之鬥爭;上個週末我添加了一個功能，通過存儲*底層*類型的詳細信息 - 這是一個非常常見的請求的難題。查看我的博客瞭解更多。 – 2011-03-13 00:21:27
看一看Protocol Buffers的位置：Fast and compact object serialization in .NET
BinaryFormatter的是好的，沒有必要拖動一個第三方的解決方案爲您的需求和它的死簡單易用。不要使用GZipStream，它只會增加開銷。內存帶寬太高，無法讓它得到回報。 – 2011-03-12 19:17:55
@Hans：他正在談論通過WAN發送數據（這可能意味着帶寬低於10Mbps）。我想'GZipStream'對於這個應用程序來說幾乎是強制性的。 – Gabe 2011-03-12 19:40:41
@加貝：錯過了，同意了。 – 2011-03-12 19:46:43