OnDataBinding vs Inline: плюсы, минусы и накладные расходы

Ответ 1

Там небольшая разница в производительности. Выражение для привязки данных анализируется и компилируется на что-то вроде

control.DataBinding += new EventHandler(ControlDataBinding);

а также

private void ControlDataBinding(object sender, EventArgs e) {
    control.Text = Eval("Field");
}

В этом случае метод OnDataBinding не переопределяется. Выполняется базовый метод Control.OnDataBinding, который вызывает событие DataBinding, заставляя выполнение вышеуказанного кода.

Когда вы переопределяете OnDataBinding, вы просто принимаете участие перед запуском базового кода и сами можете установить свойство Text (например).

Мне не нравится раздавать частичные ответы, но я сделаю это на этот раз, потому что думаю, что это аккуратно, и это спасло меня в последнее время:

Я сказал, что выражение привязки данных анализируется. Фактически, все разметки анализируются, код на С#, VB.NET или любой другой язык сгенерирован, и это они скомпилированы в класс. Когда запрашивается страница, создается экземпляр этого класса, и он начинает свою жизнь.

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

Например, у меня недавно были некоторые довольно сложные сетки Infragistics, все форматирование завершено, а затем выяснилось, что мне нужно было установить форматирование в rumtime (чтобы получить правильный формат в экспортированные файлы Excel). Для этого я открыл исходный файл (все решетки были в одном пользовательском элементе управления) и смог извлечь конфигурацию каждой сетки в отдельную группу методов.

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

Ответ 2

Я предпочитаю противоположное. Я предпочитаю, чтобы мой код не ограничивался процедурным кодом и сохранял весь мой декларативный код на моей странице Aspx. В приведенном выше примере литерал абсолютно декларативный, и поэтому (по моим предпочтениям) не будет принадлежать коду. Гораздо более надежная функциональность, как правило, входит в мой код, и я не хочу, чтобы мои разработчики были загромождены, просеивая кучу строк инициализации, пытаясь понять это.

Ответ 3

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

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

Ответ 4

На самом деле я предпочитаю использовать aspx для элементов управления, которые вы ожидаете привязать, например listview, gridview, повторитель и другие аналогичные элементы управления.

Для других элементов управления я бы установил их в codebehind, но прямо (как часть процесса, который я делаю, вместо вызова literal.DataBind или DataBind для всей страницы). Если это пользовательский/пользовательский элемент управления, я ожидаю, что вызывающие вызовы будут делать DataBind, тогда я бы переопределил DataBind и установил значения.

Тем не менее, у меня обычно есть много кода вне кода, и есть вызов для чего-то вроде ShowUser, где я помещаю эти назначения в элементы управления (вместо того, чтобы устанавливать свойство, а затем выполнять привязку и имея все эти оценки для простые элементы управления).

Ответ 5

Я согласен с калтропом. Мне нравится, чтобы моя разметка была чистой, и весь мой код aspx/ascx находился в моих файлах с кодом (где он принадлежит).

У меня есть только одна вещь для добавления. Я предпочитаю не засорять мой код событиями OnDataBinding(), проводными для каждого из моих элементов управления с помощью данных. Вместо этого я делаю все это в событии OnDataBinding() пользовательского элемента управления, которое внедряется в управляемый контроль (например, повторитель в вашем примере).

Например, в моем коде кода User Control вы найдете:

protected override void OnDataBinding(EventArgs e)
{
    base.OnDataBinding(e);

    litExample.Text = Eval("ExampleField") + " - " + Eval("ExampleField2");
}

Здесь вы можете установить свойства всех своих элементов управления или вызвать другие методы для их установки. Обратите внимание, что в моем примере мне не нужно было выполнять бокс, как вы это делали: Literal lit = (Literal)(sender);

Это само по себе должно сэкономить вам на некоторой производительности (наносекунды, конечно, но что-то стоит оценить). Прочтите раздел "Производительность" здесь: http://msdn.microsoft.com/en-us/library/yz2be5wk%28v=vs.80%29.aspx

Я тоже воюю с использованием строк в моем коде. Я бы использовал либо строковые переменные const, чтобы определить "ExampleField" и "ExampleField2", либо настроить их как общедоступные свойства в User Control, которые затем могут быть заданы с помощью содержащего элемента управления/страницы на основе имени столбца объекта данных, который он будет быть связанными. Это обеспечивает большую гибкость и повторное использование элемента управления.

FYI: вам не нужно вызывать ToString() на Eval, так как этот метод уже возвращает строку.