чем вот это
class DataItem
{
public int ID_DataItem {get; set;};
public string Data {get; set;};
}

лучше вот этого?

class DataItem
{
public int ID_DataItem;
public string Data;
}

Здравствуйте, Философ, Вы писали:

Ф>чем вот это
Ф>class DataItem
Ф>{
Ф> public int ID_DataItem {get; set;};
Ф> public string Data {get; set;};
Ф>}

Ф>лучше вот этого?

Ф>class DataItem
Ф>{
Ф> public int ID_DataItem;
Ф> public string Data;
Ф>}

Тут есть 2 лагеря. Использование полей избавляет от косвенности и позволяет легче читать код. Использование автоматических свойств позволяет засунуть какую-нибудь логику в получение и установку значения поля.

Мой подход — это использовать поля до тех пор, пока не возникнет необходимость использовать свойства.

Здравствуйте, Философ, Вы писали:

Ф>skipped
В основном тем, что:
— в случае развития DataItem и появления логики при get/set (хотя бы банального INPC), код использующий DataItem, в первом варианте не сломается;
— некоторые технологии (как примеры — data binding, ORM) завязаны на использование свойств, а не полей.

Здравствуйте, Щъмых, Вы писали:

Щ>Мой подход — это использовать поля до тех пор, пока не возникнет необходимость использовать свойства.

Такой подход хорош, если код поддерживает один квалифицированный разработчик. Если с кодом работаете не только вы, то простейший рефакторинг "обернули поле в свойство" может вылезти боком где угодно — при сериализации, биндинге, рефлексии и т.п. Самое интересное, вылезти оно может _после_ того как вы добавите и оттестируете свойство, в какой-то момент в коде окажется

  GetType("DataItem").GetField("Data"); // а чо, "Data" уже не поле???

В небольших проектах без публичного API такие вещи ещё реально отловить, в крупных — проще подстраховаться сразу и не вводить публичных полей без явной необходимости

Здравствуйте, HowardLovekraft, Вы писали:

HL>- некоторые технологии (как примеры — data binding, ORM) завязаны на использование свойств, а не полей.
да, тут согласен.
однако решарпер "решает", т.к. сгенерить заготовки свойств для полей — секундное дело


HL>- в случае развития DataItem и появления логики при get/set (хотя бы банального INPC)
чиво?
что такое INPC?

HL>, код использующий DataItem, в первом варианте не сломается;
а в первом случае, что его сломает?

Здравствуйте, Sinix, Вы писали:

S>

S>  GetType("DataItem").GetField("Data"); // а чо, "Data" уже не поле???
S>

А вот такого я вообще никогда не понимал.
Зачем лишать компилятор возможности контроля ошибок?
А если поле "Data" вообще исчезнет в процессе развития проекта (напр. разделится на 2 поля), то как потом искать все упоминания о нём?


S>В небольших проектах без публичного API такие вещи ещё реально отловить, в крупных — проще подстраховаться сразу и не вводить публичных полей без явной необходимости

вот я и спрашиваю, чем это может повредить, т.к. предыдущий пункт вообще не убедителен

Здравствуйте, Философ, Вы писали:

S>>

S>>  GetType("DataItem").GetField("Data"); // а чо, "Data" уже не поле???
S>>

Ф>А вот такого я вообще никогда не понимал.
Ф>Зачем лишать компилятор возможности контроля ошибок?
Ф>А если поле "Data" вообще исчезнет в процессе развития проекта (напр. разделится на 2 поля), то как потом искать все упоминания о нём?

Не понимайте так буквально. Например, перебор всех полей и проверка/передача их значений куда-либо и т. д. После смены "поле -> свойство" оно просто будет игнорироваться. Опять же — это только первый пришедший в голову пример. В общем — речь о том, что грабли могут полезть при использовании Reflection. Причем очень неявно.

Здравствуйте, Философ, Вы писали:

1) При необходимости добавить логику get\set сохраняется бинарная совместимость с пред. версией, с полями так не получиться


Ф>чем вот это
Ф>class DataItem
Ф>{
Ф> public int ID_DataItem {get; set;};
Ф> public string Data {get; set;};
Ф>}

Ф>лучше вот этого?

Ф>class DataItem
Ф>{
Ф> public int ID_DataItem;
Ф> public string Data;
Ф>}

Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>1) При необходимости добавить логику get\set сохраняется бинарная совместимость с пред. версией, с полями так не получиться

что понимается под бинарной совместимостью?

Здравствуйте, Философ, Вы писали:

Ф>однако решарпер "решает", т.к. сгенерить заготовки свойств для полей — секундное дело
Решарпер нифига не решает, т.к. перечень используемых сторонних, и тем более, платных (сумма не важна) инструментов далеко не всегда определяет разработчик.

Ф>что такое INPC?
Ф>а в первом случае, что его сломает?
Сокращение от INotifyPropertyChanged.

Наиболее простое и очевидное, что может быть приделано к автосвойству (да еще и DataItem'а ), это логика в сеттере для реализации INPC (решили вы его в одно прекрасное утро привязать к какому-нибудь представлению):

Было:

class DataItem
{
    public int ID_DataItem {get; set;};
    public string Data {get; set;};
}

Стало:

class DataItem : INotifyPropertyChanged
{ 
    public int ID_DataItem 
    {
        get { return iD_DataItem; }
        set
        {
             if ( != value)
             {
                 iD_DataItem = value;
                 OnPropertyChanged("ID_DataItem");
             }
        }
    }

    // ...
}

Коду, использующему DataItem, безразлично, он как вызывал пару методов get_ID_DataItem/set_DataItem, так и продолжает вызывать.

Во втором случае (когда вместо свойств были поля), клиентский код мог использовать их, например, так:

void Foo(ref int someParam)
{
}

var item = new DataItem { ID_DataItem = 100 };

Foo(ref DataItem.ID_DataItem);

Заменили на свойство — получили ошибку компиляции.

И это если мы соблюдаем правило "внесли breaking changes — поменяли asembly version". А если еще и версию не поменяли, то в рантайме получим MissingFieldException, потому как раньше было обращение к полю, а теперь требуется вызов метода.

Здравствуйте, Философ, Вы писали:

Ф>Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>>1) При необходимости добавить логику get\set сохраняется бинарная совместимость с пред. версией, с полями так не получиться

Ф>что понимается под бинарной совместимостью?

Можно подменить библиотеку новой версией, не требуя перекомпиляции использующего ее кода

Здравствуйте, Философ, Вы писали:

Ф>А вот такого я вообще никогда не понимал.
Ф>Зачем лишать компилятор возможности контроля ошибок?
На практике ошибка может быть не так очевидна, это просто самый простой пример

Ф>А если поле "Data" вообще исчезнет в процессе развития проекта (напр. разделится на 2 поля), то как потом искать все упоминания о нём?
Ну, при убирании поля обычно проводят детальный просмотр кода. При оборачивании поля в свойство — наоборот, забывают.

Ф>вот я и спрашиваю, чем это может повредить, т.к. предыдущий пункт вообще не убедителен

Ну да, так и есть. Просто любые best practices работают по принципу бэкапа:
"Пользователи делятся на тех, кто еще не делает бекапы и тех, кто уже делает"

Я уже нахватался опыта работы в "длинном" проекте без автоматического контроля за кодом, больше не хочу

Здравствуйте, Doc, Вы писали:

Doc>Здравствуйте, Философ, Вы писали:

S>>>

S>>>  GetType("DataItem").GetField("Data"); // а чо, "Data" уже не поле???
S>>>

Ф>>А вот такого я вообще никогда не понимал.
Ф>>Зачем лишать компилятор возможности контроля ошибок?
Ф>>А если поле "Data" вообще исчезнет в процессе развития проекта (напр. разделится на 2 поля), то как потом искать все упоминания о нём?

Doc>Не понимайте так буквально. Например, перебор всех полей и проверка/передача их значений куда-либо и т. д. После смены "поле -> свойство" оно просто будет игнорироваться. Опять же — это только первый пришедший в голову пример. В общем — речь о том, что грабли могут полезть при использовании Reflection. Причем очень неявно.

Reflection — вообще одни сплошные грабли, и только из-за него смена поле/свойство — это breaking change.
поломать код можно и проще:
было
public int ID_DataItem {get; set;};
стало
public int ID_DataItem {get; private set;};

а теперь десереализуем

Здравствуйте, HowardLovekraft, Вы писали:

HL>Здравствуйте, Философ, Вы писали:

Ф>>что такое INPC?
HL>Сокращение от INotifyPropertyChanged.

я его использовал, мне сокращение не знакомо было.

HL>Заменили на свойство — получили ошибку компиляции.
Не вижу ничего страшного в ошибке компиляции, поправить их — дело считанных минут.

HL>И это если мы соблюдаем правило "внесли breaking changes — поменяли asembly version". А если еще и версию не поменяли, то в рантайме получим MissingFieldException, потому как раньше было обращение к полю, а теперь требуется вызов метода.

а вот об этом не подумал, спасибо.

Здравствуйте, Философ, Вы писали:

Ф>Здравствуйте, HowardLovekraft, Вы писали:

HL>>Здравствуйте, Философ, Вы писали:

Ф>>>что такое INPC?
HL>>Сокращение от INotifyPropertyChanged.

Ф>я его использовал, мне сокращение не знакомо было.

HL>>Заменили на свойство — получили ошибку компиляции.
Ф>Не вижу ничего страшного в ошибке компиляции, поправить их — дело считанных минут.

Значит ты никогда не писал публичных АПИ. Вот представь что выпустили патч к .Net Framework, где нарушили бинарную совместимость

Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>Здравствуйте, Философ, Вы писали:

Ф>>Здравствуйте, HowardLovekraft, Вы писали:

HL>>>Здравствуйте, Философ, Вы писали:

Ф>>>>что такое INPC?
HL>>>Сокращение от INotifyPropertyChanged.

Ф>>я его использовал, мне сокращение не знакомо было.

HL>>>Заменили на свойство — получили ошибку компиляции.
Ф>>Не вижу ничего страшного в ошибке компиляции, поправить их — дело считанных минут.

ЕА>Значит ты никогда не писал публичных АПИ.

писал, почему же, но никогда в АПИ поля не выставлял наружу — как минимум был INPC, но чаще всего private/protected set.
к тому-же даже в публичных АПИ, даже от мелкософта можно встретить public fields
например Microsoft.Xna.Framework.Vector3 — хороший пример класса а-ля DataItem

Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>Здравствуйте, Философ, Вы писали:

Ф>>Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>>>1) При необходимости добавить логику get\set сохраняется бинарная совместимость с пред. версией, с полями так не получиться

Ф>>что понимается под бинарной совместимостью?

ЕА>Можно подменить библиотеку новой версией, не требуя перекомпиляции использующего ее кода

Где можно про это прочитать?

Здравствуйте, Философ, Вы писали:

Ф>Не вижу ничего страшного в ошибке компиляции, поправить их — дело считанных минут.
Эх...

Степень "ничего" обратно пропорциональна количеству человек, завязанных на этот код, и степени активности проекта.
Если вы вносите breaking changes (а замена поля на свойство — самое что ни на есть оно) в код, которым пользуется 1-3 человека, то, наверное, ничего страшного.
Если от этого зависит человек 50 хотя бы внутри вашей конторы, то в результате вам могут дать в бубен за срыв плана работ какого-то смежного подразделения, потому что им срочно нужно было исправить свои ошибки из-за ваших изменений, потом протестировать исправления, потом выпустить новую версию, которую потом нужно будет кому-то установить.

А если ваш код используют сотни, тысячи? В результате получается "опять эти индусы все поломали".

Здравствуйте, Философ, Вы писали:

Ф>Reflection — вообще одни сплошные грабли, и только из-за него смена поле/свойство — это breaking change.
Однако, без него всякие binding/mapper/undo-redo/ioc чота не пишутся.
Почему-то пока ничего лучшего никто не предложил.

Ф>поломать код можно и проще:
Ф>было
Ф>public int ID_DataItem {get; set;};
Ф>стало
Ф>public int ID_DataItem {get; private set;};
Ф>а теперь десереализуем
А вот это вы зря.
Правильный сериализатор такая мелочь не сломает. Он даже такое умеет десериализовывать:

public Collection<DataItem> Items
{
    get { return items ?? (item = new Collection<DataItem>()); } 
}
private readonly Collection<DataItem> items;

Здравствуйте, HowardLovekraft, Вы писали:

HL>Здравствуйте, Философ, Вы писали:

Ф>>Не вижу ничего страшного в ошибке компиляции, поправить их — дело считанных минут.
HL>Эх...

HL>Степень "ничего" обратно пропорциональна количеству человек, завязанных на этот код, и степени активности проекта.
HL>Если вы вносите breaking changes (а замена поля на свойство — самое что ни на есть оно) в код, которым пользуется 1-3 человека, то, наверное, ничего страшного.
HL>Если от этого зависит человек 50 хотя бы внутри вашей конторы, то в результате вам могут дать в бубен за срыв плана работ

Смена поля на свойство, как и любое изменение кода, делается не потому что левая пятка правой ноги так захотела, а потому что это реально понадобилось.
И раз уж это произошло, то в свойстве появилась какая-то логика.
Если все эти 50 человек завязаны на мой класс, то так или иначе им придётся тестировать свой код (тот же INPC иногда приводит к stack overflow)

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

Это их работа — править свои ошибки и выпускать новые версии.
А вы как хотели? Чтобы новая версия без тестирования вываливалась?


HL>А если ваш код используют сотни, тысячи? В результате получается "опять эти индусы все поломали".
демагогия

Здравствуйте, Alllie, Вы писали:


Ф>>>что понимается под бинарной совместимостью?

ЕА>>Можно подменить библиотеку новой версией, не требуя перекомпиляции использующего ее кода

A>Где можно про это прочитать?

Ну даже не знаю

Я блог Эрика Липперта регулярно читаю, у него частенько подобные вопросы разбираются. А вообще, наверно, любая книжка по .Net Framework должна давать об этом представление, сотрудников я заставляю Рихтера читать.

Здравствуйте, Философ, Вы писали:

Ф>Смена поля на свойство, как и любое изменение кода, делается не потому что левая пятка правой ноги так захотела, а потому что это реально понадобилось.
Только понадобиться может вам, а разгребать это будут все.

Ф>Это их работа — править свои ошибки и выпускать новые версии.
Это — не их ошибки, а ваше недопроектирование.

Ф>демагогия
Я не настаиваю на своей т.з.
Вы вольны раскладывать и ходить по тому количеству граблей, которое сочтете нужным.

Здравствуйте, Sinix, Вы писали:

S> проще подстраховаться сразу и не вводить публичных полей без явной необходимости
А поскольку такой необходимости просто не бывает, то правило упрощается до "никогда не использовать публичных полей".

Здравствуйте, IB, Вы писали:

IB>А поскольку такой необходимости просто не бывает, то правило упрощается до "никогда не использовать публичных полей".

Не, запрещать static readonly (если они действительно readonly)-поля для всяких ключей ресурсов и поля в структурах для интеропа — это уже перебор

Здравствуйте, Евгений Акиньшин, Вы писали:

ЕА>1) При необходимости добавить логику get\set сохраняется бинарная совместимость с пред. версией, с полями так не получиться

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

Здравствуйте, Философ, Вы писали:

Ф>чем вот это
Ф>class DataItem
Ф>{
Ф> public int ID_DataItem {get; set;};
Ф> public string Data {get; set;};
Ф>}

Ф>лучше вот этого?

Ф>class DataItem
Ф>{
Ф> public int ID_DataItem;
Ф> public string Data;
Ф>}

Тем, что экономит вам некоторое количество нажатий на кнопки при описании пропертей.

А нужно это только из-за того, что dotNet-овский Data Binding использует исключительно TypeDesctriptor, который с данными в объектах работает исключительно через Reflection GetProperty/SetProperty. Из-за него вам везде приходится использовать не поля, а проперти. Архитектура такая (странная).

Так что если вы не используете "родной" Data Binding, то вам никакой пользы от авто-пропертей нет.

С WPF вроде бы та же тема, но нужно бы еще раз проверить.

Здравствуйте, Sinix, Вы писали:

S>

S>  GetType("DataItem").GetField("Data"); // а чо, "Data" уже не поле???
S>

есть еще один пример, более легальный, который я привожу коллегам.

class MyClass1
        {
            public int MyField;
        }

        class MyClass2
        {
            public int MyField { get; set; }
        }

        static void Main(string[] args)
        {
            var a = new MyClass1();
            var b = new MyClass2();

            Foo(out a.MyField);//OK
            Foo(out b.MyField);//ERROR
        }

        static void Foo(out int value)
        {
            value = 10;
        }

Как видно код нормально работает в случае если MyField — поле, но быстро ломается, если MyField — свойство, тем самым лучше сразу делать хотя бы автосвойства, чтобы не было подобных "сюрпризов" в будущем.

Здравствуйте, sergeyt4, Вы писали:

S>А нужно это только из-за того
Во-первых, дело не только в binding. Прочитайте тему не по диагонали, и вы увидите несколько примеров.

S>Архитектура такая (странная).
Приведите пример кода, который оповестит binding engine об изменении значений, скажем, 4-х полей.
Вы ж, надеюсь, понимаете, что binding в общем случае предполагает обновление UI при изменении связанных данных?

Здравствуйте, IB, Вы писали:

IB>А поскольку такой необходимости просто не бывает, то правило упрощается до "никогда не использовать публичных полей".

Бывает Например я регулярно пользовался readonly полями (они банально меньше места занимают на экране) в простых приватных структурах с единственным конструктором-инициализатором.

Здравствуйте, alexsoff, Вы писали:

A>Здравствуйте, Sinix, Вы писали:

A>есть еще один пример, более легальный, который я привожу коллегам.

A>Как видно код нормально работает в случае если MyField — поле, но быстро ломается, если MyField — свойство, тем самым лучше сразу делать хотя бы автосвойства, чтобы не было подобных "сюрпризов" в будущем.

На мой взгляд, лучше избегать использования out для возврата значений.

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, IB, Вы писали:

IB>>А поскольку такой необходимости просто не бывает, то правило упрощается до "никогда не использовать публичных полей".

H>Бывает Например я регулярно пользовался readonly полями (они банально меньше места занимают на экране) в простых приватных структурах с единственным конструктором-инициализатором.

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

Здравствуйте, Философ, Вы писали:

Ф>чем вот это
Ф>class DataItem
Ф>{
Ф> public int ID_DataItem {get; set;};
Ф> public string Data {get; set;};
Ф>}

Ф>лучше вот этого?

Ф>class DataItem
Ф>{
Ф> public int ID_DataItem;
Ф> public string Data;
Ф>}

Ответить на этот вопрос в данной формулировке нельзя. Точнее любой ответ будет одновременно правильным и не правильным.
Как обычно, все сводится к тому, что делает этот DataItem и какой scope его использования.

Вот два диаметрально противоположных лагеря:
1. Если DataItem — это внутренний приватный класс, то разницы нет никакой, поскольку область использоваться класса ограничена очень сильно. В этом случае в любой момент времени вы сможете изменить свое решение и как угодно изменить этот класс.
2. DataItem — это часть библиотеки, которой пользуется вся ваша компания. В этом случае решение придется применять значительно более взвешенным образом: ведь теперь никакой решарпер не поможет изменить поля исходного класса на свойства, это будет breaking changes, область действия которых может распространяться на десятки других разработчиков и несколько разных команд.

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

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

Здравствуйте, sergeyt4, Вы писали:

S>Оборачивать каждый из них в проперть никакого смысла нет, и даже вредно.
Чем вредно?

Здравствуйте, HowardLovekraft, Вы писали:

HL>Здравствуйте, sergeyt4, Вы писали:

S>>Оборачивать каждый из них в проперть никакого смысла нет, и даже вредно.
HL>Чем вредно?
код загромождают, скорость доступа уменьшают, пользы не приносят.

а главное — дают искушение запихать в них какой-то код, занимающийся трансформацией данных на лету. Вот этого делать не надо, я считаю. Потому что этим должен сериализатор заниматься. Иначе вместо простого куска данных, этот клас превращается в программу, которую надо тоже поддерживать.

Максимум что можно — это атрибутов навешать, дающих сериализатору указания, как преобразовывать. И то — когда этих атрибутов становится много, уже и читабельность теряется и поддержка затрудняется.

Здравствуйте, HowardLovekraft, Вы писали:

HL>Здравствуйте, sergeyt4, Вы писали:

S>>Оборачивать каждый из них в проперть никакого смысла нет, и даже вредно.
HL>Чем вредно?

Вредно для зрения

Здравствуйте, hardcase, Вы писали:

H>Бывает Например я регулярно пользовался readonly полями (они банально меньше места занимают на экране) в простых приватных структурах с единственным конструктором-инициализатором.
О да — прямо синтаксический оверхэд.
Я таки вспомнил единственный сценарий когда это нужно — для набора констант, которые нужно передать в атрибут, но это уж совсем вырожденный случай и то можно enum-ами попробовать выкрутиться. Во всех остальных случаях за публичные поля — линейкой по пальцам. =)

Здравствуйте, sergeyt4, Вы писали:

S>Есть еще один сценарий: поля в классах/структурах, которые используются в интерфейсах между клиентом и сервером. Полей бывает много, и все они нужны только для того, чтобы сервер в них что-то положил, а клиент забрал и забыл про эти классы. Оборачивать каждый из них в проперть никакого смысла нет, и даже вредно.
Ровно наоборот, это как раз тот случай когда нужно использовать только свойства без всяких оговорок. Разработчику вообще вредно выбор давать, начинают тут философствовать — поле, свойство, тут мне писать лень, тут смотрится некрасиво, а потом разгребай за ними.

Здравствуйте, sergeyt4, Вы писали:

S>код загромождают, скорость доступа уменьшают, пользы не приносят.
Еще один борец за синтаксический оверхэд.. ) Сколько символов ты планируешь на этом сэкономить?
И пеналти по перфомансу тут конечно невыносимый, если, конечно, получится разглядеть его в микроскоп по сравнению с сериализацией/десериализацией.
Зато польза очевидна, начиная от гарантии бинарной совместимости (что особенно важно в клиент-серверных сценариях) и заканчивая возможностью использовать тот же TypeDescriptor (что эффективнее) для выше упомянутой кастомной сериализации. Ну это если не продолжать упорствовать в своих заблуждениях конечно же )

S>а главное — дают искушение запихать в них какой-то код, занимающийся трансформацией данных на лету.
Тех у кого появляются такие искушения, никакие поля не спасут.

Здравствуйте, IB, Вы писали:


IB>И пеналти по перфомансу тут конечно невыносимый, если, конечно, получится разглядеть его...

вот тут он кстати, может оказаться прав — до сериализатора иногда ещё доползти надо.
например для Vector2D/Vector3D "пенальти" очень даже может иметь значение.

народ вон как до сих пор извращается чтоб лишние такты выжать:
http://www.gamedev.ru/code/tip/?id=3820
http://www.gamedev.ru/code/tip/advfloat

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

S>На мой взгляд, лучше избегать использования out для возврата значений.
It depends, лично я взял для себя практику — всегда допускаю не больше 1 out-параметра в методе, если нужно больше, оборачиваю в класс.

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, sergeyt4, Вы писали:

S>>код загромождают, скорость доступа уменьшают, пользы не приносят.
IB>Еще один борец за синтаксический оверхэд.. ) Сколько символов ты планируешь на этом сэкономить?
IB>И пеналти по перфомансу тут конечно невыносимый, если, конечно, получится разглядеть его в микроскоп по сравнению с сериализацией/десериализацией.

Ну тут согласен, потери не сильно большие, если свойства напрямую вызывать. Или хотя бы через скомпилированный dynamic delegate.

IB>Зато польза очевидна, начиная от гарантии бинарной совместимости (что особенно важно в клиент-серверных сценариях) и заканчивая возможностью использовать тот же TypeDescriptor (что эффективнее) для выше упомянутой кастомной сериализации. Ну это если не продолжать упорствовать в своих заблуждениях конечно же )

Но вот эффективность TypeDescriptor-а я поставлю под большое сомнение: доступ к данным он осуществляет с помощью Reflection, который доказал свою супермедлительность.

Здравствуйте, sergeyt4, Вы писали:

S>Но вот эффективность TypeDescriptor-а я поставлю под большое сомнение: доступ к данным он осуществляет с помощью Reflection, который доказал свою супермедлительность.
Угу, только TypeDescriptor кеширует этот доступ.

Здравствуйте, IB, Вы писали:

IB>Здравствуйте, sergeyt4, Вы писали:

S>>Но вот эффективность TypeDescriptor-а я поставлю под большое сомнение: доступ к данным он осуществляет с помощью Reflection, который доказал свою супермедлительность.
IB>Угу, только TypeDescriptor кеширует этот доступ.

Что же он кэширует? PropertyInfo? И то хорошо...

Но обращение-то к пропертям класса в любом случае происходит через MethodInfo.Invoke. На set и на get. А это во много раз тормознее прямого доступа или dynamic delegate. Помню, мы когда-то тестировали Reflection, разница в тысячи раз была...