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

Question

Я подумал, что задам этот вопрос, чтобы понять, почему многие примеры и люди предпочитают использовать встроенную привязку данных в коде aspx вместо реализации события OnDataBinding при использовании WebForms.

Для любого элемента управления с привязкой к данным (например, Repeater, GridView и т. Д.) Я всегда реализую метод OnDataBinding для элементов управления уровня поля, если мне нужно сделать что-то, что не встроено из коробки (например, Мне нужно сделать Эвал). Большинство примеров, которые я вижу, имеют код прямо на странице aspx с использованием встроенного синтаксиса <% #. </p>

Пример встроенного кода ASP.NET:

<asp:Literal ID="litExample" runat="server"
    Text='<%# Eval("ExampleField").ToString() %>' />

Пример того, как я предпочитаю это делать:

В aspx:

<asp:Literal ID="litExample" runat="server" 
    OnDataBinding="litExample_DataBinding" />

В коде позади .cs:

protected void litExample_DataBinding(object sender, System.EventArgs e)
{
    Literal lit = (Literal)(sender);
    lit.Text = string.Format("{1} - {2}",
        Eval("ExampleField").ToString(),
        Eval("ExampleField2").ToString());
}

Я лично предпочитаю метод codebehind, потому что он поддерживает чистоту моих страниц aspx, и у меня нет всего этого встроенного кода повсюду, и следующий парень просто знает, что всегда ищет в файлах .cs изменения кода. Разделение представления и кода также поддерживается таким образом, поскольку HTML-код является только заполнителями, а кодовая привязка определяет, что на самом деле передается под контроль.

Теперь это очень простые примеры. Поле может быть целым числом, которое вы хотите отформатировать с ведущими 0 или DateTime, для которого требуется определенный формат и т. Д. Также могут потребоваться все виды манипуляций и кода, чтобы получить окончательное значение, которое должно храниться в свойстве «Текст» по адресу конец.

Где вы рисуете линию и перемещаете ее в код, если вы используете встроенный код?

Каковы плюсы и минусы в том или ином случае?

Один из них требует больше ресурсов, чем другой?

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

Редактировать Примечание: Я думал, что получу больше откликов, особенно в отношении накладных расходов. Большинство людей НЕ используют события OnDataBinding?

Answer 1

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

Answer 2

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

control.DataBinding += new EventHandler(ControlDataBinding);

, а также

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

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

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

---

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

Например, в коде моего пользовательского элемента управления вы найдете:

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», либо установил бы их как публичные свойства в пользовательском элементе управления, которые затем можно было бы установить с помощью содержащего элемента управления / страницы на основе имени столбца объекта данных, который будет быть связанным с. Это обеспечивает большую гибкость и повторное использование элемента управления.

К вашему сведению: вам не нужно вызывать ToString () для Eval, так как этот метод уже возвращает строку.

Answer 5

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

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

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