Лучшие практики для DataBinding в asp.net для пригодности для обслуживания

Хороший вопрос!

Насколько привязка данных идет, необходимо посмотреть на нее как только на один компонент полной стратегии доступа к данным. Моя стратегия имеет три компонента (я добираюсь до Вашего DataBinding в 2 компонента):

Во-первых, я всегда создаю (или повторное использование, главным образом) Уровень доступа к данным (DAL) для упрощения доступа к данным. Это - то, не потому что я могу когда-нибудь выгрузить Вашу базу данных для другого - шансы этого являются достаточно небольшими, что она не гарантирует всю работу, это требовалось бы (YAGNI). Вы делаете это так, чтобы можно было A) удалить всю помеху из нормального кода базы данных (например, получение строки подключения, установка и заключительные соединения, и т.д.) и B) упростить общие операции со специализированными функциями.

Во-вторых, абсолютно необходимо реализовать ObjectDataSources, которые инкапсулируют DataBinding для средств управления UI. При создании хорошего DAL это становится довольно тривиальным. Например, вот ObjectDataSource, который использует мой DAL:

    [DataObjectMethodAttribute(DataObjectMethodType.Select, true)]
    public List<EnrollListMemberData> GetNameList(int classID, DateTime classDate)
    {
        using (BSDIQuery qry = new BSDIQuery())
        {
            return
                qry.Command(
                    "Select a.ClassDate, a.ClientID, b.FirstName, b.LastName, b.ID From ClassEnroll a inner join Folder b on (a.ClientID = b.ClientID) Where (a.ClassID=@ClassID) AND ")
                    .ParamVal(classID)
                    .Append("(DateDiff(d, a.ClassDate, @ClassDate) = 0) Order By LastName;")
                    .ParamVal(classDate)
                    .ReturnList<EnrollListMemberData>();
        }
    }

Несколько вещей отметить: атрибут "DataObjectMethodAttribute" сделает этот метод видимым к среде проектирования так, чтобы Вы видели его в выпадающем списке источников данных, когда Вы пойдете для соединения Сетки (или безотносительно). Вам также будет нужен [DataObjectAttribute] атрибут на классе, который предоставляет этот метод (этот класс если часть моего Бизнес-Слоя). Наконец, это - довольно простой пример и не имеет некоторых общих конструкций, таких как startRowIndex и maximumRows параметры для возврата разбитых на страницы результатов.

Обратите внимание, что конкретный вызов здесь от моего DAL - это не LinqToSQL даже при том, что он имеет поверхностное подобие. Мне нравится SQL, и я не хочу идиомы C#, которые просто имеют произвольное отображение назад на SQL так или иначе. Обратите внимание, что, если бы я попытался реализовать все это в прямых вызовах ADO, эта функция была бы в три раза более долгой и имела бы много кода, который действительно не был релевантен выражению моих целей.

В-третьих, я всегда помещаю многоступенчатые операции базы данных в хранимые процедуры для уменьшения количества перекличек провод к базе данных. Например, я обеспечиваю функцию "Check In" в одном продукте, который берет регистрацию запроса, проверяет его по таблице членства, получает предыдущую регистрацию истории (сколько посещений в прошлом месяце?), присуждает побудительные очки при необходимости, и т.д. и т.д. Выполнение нескольких запросов и изменений в базе данных в коде C# было бы ужасно сложным и довольно дорогим. В соответствии с нашей философией DAL, я также инкапсулирую вызов к хранимой процедуре в моем DAL так, чтобы фактический вызов из кода был справедлив:

международное состояние = dal. CheckIn (идентификатор пользователя, касательно checkInHistory);

Как Вы видите, использование хранимой процедуры и инкапсуляция ее в методе класса C# также делают код намного легче читать. В моем коде просто говорится, что он делает (как выше) вместо того, чтобы иметь 100 + строки кода, настраивающего запросы и т.д.

Я надеюсь, что это помогает!

Только ради полноты, я хочу добавить это о своем комментарии в первом ответе.

Я задал следующий вопрос:

если Вы связываете с данными от codebehind, необходимо будет все еще определить поля в разметке. Как Вы удостоверились бы, что изменения в Ваших бизнес-объектах не повредят страницы?

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

Exemple:

<%# ((ObjetType)Container.DataItem).PropertyName %>

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