Как избежать «Связывания с большими объектами CLR»?

Question

В этом руководстве по оптимизации DataBinding говорится:

Существенное влияние на производительность оказывает привязка данных к одному объекту CLR с тысячами свойств. Вы можете минимизировать это влияние, разделив один объект на несколько объектов CLR с меньшим количеством свойств.

1. Что это значит? Я все еще пытаюсь ознакомиться с DataBinding, но моя аналогия здесь заключается в том, что свойства похожи на поля таблицы SQL, а объекты - на строки. Этот совет затем переводится как «чтобы избежать проблем с большим количеством полей, используйте меньше полей и создайте больше строк». Поскольку это не имеет никакого смысла для меня, возможно, мое понимание привязки данных полностью изменено?

2. Применим ли этот совет на самом деле? Я не уверен, относится ли он к .NET 4 / WPF, хотя я использую 3.5 и пользовательскую библиотеку управления на основе WinForms (DevExpress)

3. В качестве отступления: правильно ли я считаю, что DataBinding использует отражение при использовании источника данных в стиле IList?

Это не просто академический вопрос. В настоящее время я пытаюсь ускорить загрузку XtraGridView (DevExpress Control) с ~ 100 000 объектов с 50 свойствами или около того.

Answer 1

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

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

Answer 2

Этот совет затем переводится как «чтобы избежать проблем с большим количеством полей, используйте меньше полей и создавайте больше строк» ​​

Я думаю, что это следует перевести как «использовать меньше полей исоздать меньшие таблицы"(т.е. с меньшим количеством полей).И оригинальный совет должен гласить «[...] разделение одного класса на несколько классов» с меньшим количеством свойств.Как вы правильно заметили, не имеет смысла создавать больше «строк» ​​...

В любом случае, если у вас do есть класс, который предоставляет сотни или тысячи свойств, у вас естьгораздо более серьезная проблема, чем производительность привязки ... Это серьезный недостаток дизайна, который следует исправить после прочтения некоторых принципов OO .

Применим ли этот совет на самом деле?Я не уверен, относится ли он к .NET 4 / WPF, хотя я использую 3.5 и пользовательскую библиотеку управления на основе WinForms (DevExpress)

Что ж, упомянутая вами страница посвящена WPF, но ядумаю, что идея связывания с более мелкими объектами может быть применима и к WinForms (поскольку чем больше свойств нужно наблюдать, тем медленнее будет)

В качестве отступления: я прав в том, что DataBinding использует отражениекогда используется источник данных в стиле IList?

Вы частично правы ... он на самом деле использует TypeDescriptor, который, в свою очередь, использует отражение для проверки обычных объектов CLR.Но этот механизм гораздо более гибкий, чем рефлексия: тип может реализовать ICustomTypeDescriptor для предоставления своего собственного описания, списка членов и т. Д. (DataTable - один из примеров такого типа)