OnDataBinding по сравнению со Встроенным: профессионалы, недостатки и наверху
Вы создаете новый Date в DateUtil!
public static String getFormattedDate(Date date, String pattern) {
DateFormat dateFormat = new SimpleDateFormat(pattern);
return dateFormat.format(new Date()); // change it to the date passed in!
}
4 ответа
Между ними небольшая разница в производительности. Выражение привязки данных анализируется и компилируется в нечто вроде
control.DataBinding += new EventHandler(ControlDataBinding);
, а также
private void ControlDataBinding(object sender, EventArgs e) {
control.Text = Eval("Field");
}
. В этом случае метод OnDataBinding не переопределяется. Выполняется базовый метод Control.OnDataBinding, который вызывает событие DataBinding, вызывая выполнение вышеуказанного кода.
Когда вы переопределяете OnDataBinding, вы просто берете на себя управление до того, как будет запущен базовый код, и можете установить Текст свойство (например).
Мне не нравится давать частичные ответы, но я сделаю это на этот раз, потому что считаю это аккуратным, и это меня недавно спасло:
Я сказал, что данные выражение привязки анализируется. Фактически, вся разметка анализируется, создается код на C #, VB.NET или другом языке, и это они компилируются в класс. Когда страница запрашивается, создается экземпляр этого класса, и он начинает свою жизнь.
Вы можете найти эти сгенерированные файлы кода на диске извините, я не помню где . Интересно то, что они все еще работают как код.
Например, недавно у меня были настроены довольно сложные сетки Infragistics, все форматирование было завершено, а затем я обнаружил, что мне нужно установить форматирование в Rumtime (чтобы получить правильный формат в экспортируемых файлах Excel). Для этого я открыл исходный файл (все сетки находились в едином пользовательском элементе управления) и смог выделить конфигурацию каждой сетки в отдельную группу методов.
Я смог очистить их с помощью ReSharper , извлекать общие кодовые последовательности в базовый класс, и остался один статический метод для настройки каждой сетки.
Я очень предпочитаю противоположное. Я предпочитаю сохранять свой код - позади ограниченного процессуальным кодексом и сохранять весь мой декларативный код на моей странице Aspx. В Вашем примере выше, литерал абсолютно декларативен, и поэтому (моим предпочтением) не принадлежал бы кода - позади. Намного больше надежной функциональности обычно входит в мой код - позади, и я не хочу, чтобы мои разработчики были нарушены при необходимости отсеять через набор строк инициализации при попытке понять это.
На самом деле я предпочитаю использовать aspx для средств управления, которые Вы ожидали бы Связывать, как listview, gridview, повторитель и другие подобные средства управления.
Для других средств управления я установил бы их в codebehind, но непосредственно (как часть процесса я делаю, вместо того, чтобы назвать литерал. DataBind или DataBind для целой страницы). Если это - пользователь/пользовательский элемент управления, что я ожидаю, что вызывающие стороны сделают DataBind, то я переопределил бы DataBind и установил бы значения.
Тем не менее у меня обычно есть много кода вне codebehind, и имейте вызов к чему-то как ShowUser, куда я поместил те присвоения на средства управления (вместо того, чтобы установить свойство, затем делая связывание, и имея все те evals для простых средств управления).
Я предпочитаю ваш вариант с OnDataBinding. Вы можете поддерживать свой код в чистоте, используя область «Databind» для всех вызовов OnDataBinding, и вы можете поддерживать чистоту разметки, извлекая оттуда ужасные блоки кода на стороне сервера.
Я думаю, что большинство людей делают это встроенным способом, потому что его легче понять и реализовать.