Charles WeylandВ чём преимущество пустого свойства перед полем?
1. Если захочется добавить логику и преобразовать поле в свойство, то придётся перекомпилировать вызывающий код. Если такая возможность есть, то это некритично - например, когда поле или класс описаны как private или internal.

2. Есть разница на уровне рефлекшена. Как следствие, не каждый сериализатор, датабиндинг и т. п. умеет работать с полями из-за лени их создателей.

зы: В древности люди считали, что по ряду причин не должно быть публичных полей классов. Некоторые до сих пор так считают.

hVosttДля авто-свойства компилятор сгенерирует приватное поле и назовёт его как ему вздумается. Поэтому есть вероятность, что ты получишь фейл, при десериализации. Крайне редкий и специфичный случай, который может неожиданно огорчить =)Все известные науке сериализаторы игнорируют приватные члены. Ну может если только их явно атрибутом каким пометить. Что же там такое ужасное может случиться? Давай пример.

hVosttАлексей К,

http://www.infragistics.com/community/blogs/josh_smith/archive/2008/02/05/automatic-properties-and-the-binaryformatter.aspx

авторI think a good rule of thumb is: do not use automatic properties in serializable types .

Ну да, древний BinaryFormatter почему-то пишет приватные поля. Нажно всем отказываться от автосвойств... :-)

*Нужно

hVosttАлексей КНу да, древний BinaryFormatter почему-то пишет приватные поля. Нажно всем отказываться от автосвойств... :-)

Ну по сути это как раз и есть честный сериализер. Все другие, о которых ты говоришь, никак не гарантируют, что сериализованные данные будут идентичны десериализованным хоть в какой-то мере. Любое свойство может намерянно или нет искажать данные. О чём собственно и говорил Рихтер. Правда как оказалось не так страшен чёрт, как его малюют, но это делает ситуацию ещё более опасной Никакой опасности для тех, кто не нарушает концепцию свойств и понимает, что в них должно находиться. :-)

С другой стороны, BinaryFormatter пользуется не публичным контрактом класса, как принято в приличном обществе, он лезет в святая святых - в приватные поля, из-за чего и работает неправильно при некоторых, вполне законных , изменениях внутренностей класса. Авторы BinaryFormatter должны признать свои ошибки и сделать что-нибудь хорошее, чтобы загладить вину перед обществом.

hVosttАлексей КС другой стороны, BinaryFormatter пользуется не публичным контрактом класса, как принято в приличном обществе, он лезет в святая святых - в приватные поля, из-за чего и работает неправильно при некоторых, вполне законных , изменениях внутренностей класса. Авторы BinaryFormatter должны признать свои ошибки и сделать что-нибудь хорошее, чтобы загладить вину перед обществом.

В некоторых случаях это идеальный вариант. Например, сериализация исключений.ОК. Подумаю об этом. Но на первый взгляд похоже на авантюру. :-)

hVosttАлексей КОК. Подумаю об этом. Но на первый взгляд похоже на авантюру. :-)

Насчёт авантюры согласен, замахнулись не подумав. С бинарной сериализацией связано целое корыто проблем, поэтому и не обрело популярности.Бинарные сериализаторы разные бывают. В WCF есть бинарный сериализатор, который нормально работает.

hVosttАлексей КБинарные сериализаторы разные бывают. В WCF есть бинарный сериализатор, который нормально работает.

Медленный он... если если ты конечно имеешь в виду BinaryFormatter. Лучше ProtoBuf =)Ну я про сериализатор, используемый в привязке WCF NetTCP. С чего он медленный-то? Да и мы разве куда-то не успеваем? :-)

skyANAАлексей Кпропущено...
Ну я про сериализатор, используемый в привязке WCF NetTCP. С чего он медленный-то?
Не тестировал, но скорее всего из-за рефлексии.Ну там, если всё по уму написано, должна быть кодогенерация через Emit или Expression. Но я тоже не тестировал. :-)

skyANAАлексей Кпропущено...
Ну там, если всё по уму написано, должна быть кодогенерация через Emit или Expression. Но я тоже не тестировал. :-)
Ты хотел сказать, если написать самому генерацию суррогата для каждого класса, что необходимо сериализовать?Ну нет. Я про кодогенерацию внутри сериализатора, как в XmlSerializer.

skyANAАлексей Кпропущено...
Ну нет. Я про кодогенерацию внутри сериализатора, как в XmlSerializer.
А она появилась для Binary? Раньше помнится самому надо было писать.Ну в WCF в сериализаторе для NetTCP может и есть, надо уточнять. Могу ошибаться конечно же.

Сон Веры ПавловныАлексей КЯ про кодогенерацию внутри сериализатора, как в XmlSerializer.
Кхм... может, лучше не надо?Возможные утечки памяти описаны в документации . Просто не все её читают.
авторTo increase performance, the XML serialization infrastructure dynamically generates assemblies to serialize and deserialize specified types. The infrastructure finds and reuses those assemblies. This behavior occurs only when using the following constructors:

XmlSerializer.XmlSerializer(Type)

XmlSerializer.XmlSerializer(Type, String)

If you use any of the other constructors, multiple versions of the same assembly are generated and never unloaded, which results in a memory leak and poor performance. The easiest solution is to use one of the previously mentioned two constructors. Otherwise, you must cache the assemblies in a Hashtable, as shown in the following example.

ЕвгенийВskyANAпропущено...

О чем ты вообще?
О том, что палка о двух концах.
С одной стороны нужно быстро.
С другой, не каждый класс можно сериализовать, например трудности с Expression<TDelegate> или Thread. И нужно постараться, что бы как можно больше типов были подвержены сериализации, там что бы разрулить например одни циклические ссылки, нужно здорово постараться, сложность не меньше, чем у GC получиться. На написание сериализатора тратить столько не оправдано.
Вот и дано, хочешь используй стандартный, не хочешь - пиши кастомный.Не надо бездумно в одном классе смешивать логику и данные, тогда не будет никаких палок с концами.