Почему DataContractSerializer не реализует IFormatter?

Question

Я получаю немного разочарованы отсутствием согласованности в рамках различных форм сериализации в .NET:

• DataContractSerializer - использует новые атрибуты или старые [Serializable] атрибутов, но сам сериализатору не реализует IFormatter, где делают некоторые из других сериализаторов WCF. Выбрать в.

• NetDataContractSerializer - использует новые атрибуты ИЛИ старый, serializer реализует IFormatter, совместим с WCF и является опцией IN. Кажется идеальным решением!

• XmlSerializer - полностью независимый набор атрибутов, но является наследием, поэтому может простить это.

• BinaryFormatter - реализует IFormatter и использует атрибуты [Serializable]. Отказаться.

Так что мой вопрос в том, почему DataContractSerializer не остается по крайней мере относительно взаимозаменяемым с BinaryFormatter?

Мне очень жаль, что они с самого начала не договорились об этом с чистым интерфейсом, это позор действительно на просторах платформы .NET, которая обычно так упорядочена!

Редактировать: Только для тех, кто интересуется (я знаю, что это действительно не относится к остальной теме), я делал некоторое время и размер, сравнивая то, что я воспринимаю как наиболее вероятный «на -wire»методы сериализации:

============ Serialization ============ 

Protobuf  x158,194 39,549 per/sec 1.00 
OldFieldbase x58,191 14,548 per/sec 2.72 
Fieldbase  x57,445 14,361 per/sec 2.75 
DataContract x54,611 13,653 per/sec 2.90 
Binary  x29,466 7,367 per/sec 5.37 
Net   x28,170 7,043 per/sec 5.62 
Json   x10,605 2,651 per/sec 14.92 

И размеры:

============ SerializationSizes ============ 

Protobuffers 209 bytes 1.00 
Fieldbase  246 bytes 1.18 
OldFieldbase 248 bytes 1.19 
Json   728 bytes 3.48 
DataContract 1227 bytes 5.87 
Net   1658 bytes 7.93 
Binary  1826 bytes 8.74 

Примечание: на Core2 T9300 (однопоточный) + 4 ГБ.

Answer 1

я могу думать о двух возможных причин, почему DataContractSerializer не реализует IFormatter:

• производительности - DCS был переделан специально, чтобы быть как можно быстрее, так как WCF тяжело и часто полагается на объект сериализации/десериализации - это одна из причин, по которым DCS не поддерживает, например атрибуты на узлах XML; со всем этим, это примерно на 10% быстрее, чем XmlSerializer

• Взаимодействие - помните, что WCF был построен из get-go, чтобы быть как можно совместимым, а не .NET с .NET, но совместимым с любым количество других систем, таких как Java, Ruby, - вы называете это; ни BinaryFormatter, ни XmlSerializer, ни NetDataContractSerializer не могут использоваться в совместимом сценарии - все они специфичны для .NET и доступны только и доступны.NET

Это общая проблема - многие .NET разработчики просто забывают, что WCF является не .NET, специфичен и только технологиями .NET - он должен стремиться поддерживать максимальную совместимость, насколько это возможно с большим других систем, которые могут не предлагать все возможности .NET. Другим примером является обработка ошибок в WCF - не просто бросайте .NET-исключения - они специфичны для .NET и не имеют значения для клиента Java - используйте ошибки SOAP в ваших службах WCF! (если вы не можете быть на 100% уверены, что ни один клиент не-NET не будет когда-либо вызовет вашу услугу)

Answer 2

В сериализации DataContract используется стратегия opt-in, где вы должны явно указывать элементы для сериализации, а по умолчанию не следует сериализовать элемент. Сериализация с использованием атрибута [Serializable] использует стратегию отказа , где все члены объекта [Serializable] сериализуются по умолчанию, если не отмечены как [NonSerialized].

Это намеренно, чтобы предотвратить случайные изменения контрактов данных путем добавления полей или свойств к объектам контракта данных.