Опубликован: 14.11.2006 | Уровень: для всех | Доступ: платный
Лекция 7:

Работа с базами данных (продолжение). Элементы-источники данных (Data Source Controls)

< Лекция 6 || Лекция 7: 1234 || Лекция 8 >

Кэширование

Кэширование нужно для увеличения эффективности работы с данными. При включенном кэшировании SqlDataSource "запоминает" большое количество записей на заданное время, даже если все данные не отображаются сразу, но могут понадобиться при перелистывании. Например, студент читает первую страницу лекции, логично, что он вскоре перейдет ко второй. Если сервер хранит в оперативной памяти все страницы лекции, он их оперативно выдаст, не обращаясь к базе.

При включенном кэшировании данные читаются "большим куском", а выборка записей происходит с помощью фильтрования.

В SqlDataSource кэширование и сортировка возможны только при получении данных через DataSet. Если DataSourceMode равно DataReader, а EnableCachingTrue, будет выброшено исключение NonSupportedException.

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

Поведение кэширования зависит от сочетания свойств CacheDuration и CacheExpirationPolicy. Если значение CacheExpiration Policy равно Absolute, то элемент запрашивает информацию через промежутки времени, определенные в CacheDuration, а старую стирает из памяти. Если CacheExpirationPolicy равен значению Sliding, то SqlDataSource начинает отсчет времени после каждого запроса к нему. Данные из кэша устаревают, если в течение времени CacheDuration не было ни одного Select -запроса.

В FilterExpression задается выражение для фильтрации, причем формат этих выражений аналогичен тому, что используется для форматирования строк с параметрами в фигурных скобках {0}, {1}, в которые подставляются значения из источника, указанного в Filter Parameters:

<asp:SqlDataSource ID="SqlDataSource1" runat="server" 
ConnectionString="<%$ ConnectionStrings:NorthwindConnectionString %>"
    SelectCommand="SELECT * FROM [Customers]" ProviderName="<%$ 
ConnectionStrings:NorthwindConnectionString.ProviderName %>"
    EnableCaching="True" CacheExpirationPolicy="Sliding">
</asp:SqlDataSource>

У этого элемента включено кэширование, и он является источником данных для GridView.

<asp:SqlDataSource ID="SqlDataSource2" runat="server" 
ConnectionString="<%$ ConnectionStrings:NorthwindConnectionString %>"
    SelectCommand="SELECT * FROM [Customers]" ProviderName="<%$ 
ConnectionStrings:NorthwindConnectionString.ProviderName %>"
FilterExpression="CustomerID=’{0}’ "
<FilterParameters>
<asp:ControlParameter Name="CustomerID" ControlId="GridView1"
PropertyName="SelectedValue"></asp:ControlParameter>
</FilterParameters>
    </asp:SqlDataSource>

А у этого включена фильтрация, и он является источником данных для DetailsView. Элемент управления DetailsView всегда отображает одну запись, при этом в данном случае это та запись, которая выбрана в контроле GridView1.

Сортировка

В свойстве SortParameterName можно записать список полей, по которым проводится сортировка, возможно с добавлением опции Desc для сортировки в порядке убывания. Параметры передаются в команду Select, если это серверная процедура.

ObjectDataSource

Как уже было сказано, этот класс работает с бизнес-объектами. А что же это такое? Это такие классы, которые инкапсулируют логику работы с данными, нужными в приложении. Класс бизнес-объекта может быть написан на любом языке .NET. Как и все классы, он располагается в папке App_Code. ObjectDataSource работает как связующее звено между бизнес-объектами и элементами управления, отображающими данные. Получается многоуровневая компонентная архитектура. Классы бизнес-объектов могут поменять свое внутреннее представление, и это никак не отразится на страницах, которые их используют. ObjectDataSource работает во многом так же, как SqlDataSource, с той разницей, что он имеет дело не с базой данных, а с классом.

Свойство TypeName класса ObjectDataSource указывает на используемый класс. Класс бизнес-объекта должен поддерживать конструктор и 4 метода (возможно, и больше) — для чтения, редактирования, удаления и добавления данных в источник данных. Элемент управления ObjectDataSource пользуется этими методами.

Например, свойство SelectMethod указывает на метод класса бизнес-объекта, который возвращает данные.

Откуда бизнес-объект берет данные, ему не важно. Некоторые бизнес-объекты работают с базами данных, некоторые — с сессией или текстовыми файлами. Главное, что метод, который он использует для чтения, должен возвращать класс, реализующий интерфейс IEnumerable. UpdateMethod — метод, который обновляет данные. Аналогичную функцию выполняют DeleteMethod и InsertMethod.

Класс бизнес-объекта может поддерживать метод SelectCount, который возвращает общее количество объектов в источнике данных. ObjectDataSource вызывает этот метод, чтобы реализовать разбиение на страницы.

Рассмотрим это на примере:

public class Continent
{
    ArrayList ContinentArrayList;
    public Continent()
    {
        ContinentArrayList = new ArrayList();
        ContinentArrayList.Add("Worldwide");
        ContinentArrayList.Add("America");
        ContinentArrayList.Add("Africa");
        ContinentArrayList. Add("Asia-Pacific");

    }
    public ArrayList List()
    {
        return ContinentArrayList;
    }
    public int SelectCount()
    {
        return ContinentArrayList.Count;
    }
}

Даже такой примитивный класс может использоваться как источник данных для ObjectDataSource, так как ArrayList реализует IEnumerable. Вместо свойств *Command ObjectDataSource использует *Method:

<asp:ObjectDataSource ID="ObjectDataSource1" runat="server"
     SelectMethod="List" TypeName="Continent">
</asp:ObjectDataSource>
<asp:RadioButtonList ID="RadioButtonList1" runat="server" 
    DataSourceID="ObjectDataSource1">
</asp:RadioButtonList></div>

Достигается тот же эффект, что и раньше, когда данные вставлялись на странице или в классе страницы, но теперь получение данных инкапсулировано в классе Continent. Класс может изменить способ получения данных, не меняя интерфейса. Чаще всего данные все-таки получают из баз данных, XML-файлов или web-сервисов. Классы бизнес-логики могут разрабатывать одни члены команды, а заниматься дизайном страниц — другие. Их можно использовать и в обычных приложениях в Windows Forms.

ObjectDataSource может работать и с типизированными наборами данных, которые можно создать с помощью мастера. Попробуем это сделать на примере таблицы Customers. Создайте в папке App_Code новый файл и в диалоге выбора типа файла выберите dataset. Назовите его Customers. Мастер предложит выбрать строку соединения. Выберите NorthWindConnectionString (если его нет в проекте, создайте, как показано в предыдущей лекции). На следующем шаге мастер предложит выбрать из трех вариантов: использование запросов SQL, создание хранимых процедур или использование готовых процедур. Выберите второе, так как готовых процедур, которые бы обновляли данные, в базе Northwind нет. На следующем шаге нужно будет создать процедуры, это можно сделать с помощью QueryBuilder, очень похожем на дизайнер запросов в MS Access. В списке таблиц выберите Customers, а в таблице несколько полей. Должен получиться запрос

SELECT CustomerID, CompanyName, ContactName, ContactTitle, Country, City FROM Customers
< Лекция 6 || Лекция 7: 1234 || Лекция 8 >
Алексей Савельев
Алексей Савельев

https://technet.microsoft.com/en-us/library/ms143221(v=sql.105).aspx

Денис Прокофьев
Денис Прокофьев

Везде написано, что это самый независимый и простой в использовании навигационный элемент управления, что он работает сразу с web.sitemap и не требует определения SiteMapDataSource.

Моя карта сайта состоит из двух страниц, вложенных друг в друга. asp:Menu, asp:TreeView отбображаются как ожидалось, а вот asp:SiteMapPath - нет. Он не виден нигде. Однако на его месте формируется разметка: <span id="SiteMapPath1"><a href="#SiteMapPath1_SkipLink" style="position:absolute;left:-10000px;top:auto;width:1px;height:1px;overflow:hidden;">Проход по ссылкам навигации</a><a id="SiteMapPath1_SkipLink"></a></span> - т.е. элемент отрабатывает.

В словах xHTML это выглядит так: <asp:SiteMapPath ID="SiteMapPath1" runat="server" />. Причем не важно - внутри тега form или снаружи - всегда одинаково.

Т.к. другие нав. ЭУ работают через простой источник данных без ошибок, делаю вывод - карта составлена правильно. ИД: <asp:SiteMapDataSource ID="SiteMapDataSource1" runat="server" />

Карта: <?xml version="1.0" encoding="utf-8" ?>
<siteMap xmlns="http://schemas.microsoft.com/AspNet/SiteMap-File-1.0" >
  <siteMapNode url="~/L11_1_simplePage.aspx" title="Страница 1"  description="Простая страница 1." >
    <siteMapNode url="~/L11_1SimplePage2.aspx" title="Страница 2"  description="Простая страница 2" />
  </siteMapNode>
</siteMap>

Почему так происходит? Вроде делаю все по примерам. VS Community 2015. NetFramework в проекте: v4.0.30319

Зарина Каримова
Зарина Каримова
Казахстан, Алматы, Гимназия им. Ахмета Байтурсынова №139, 2008
Akiyev Begench
Akiyev Begench
Беларусь, Полоцк, полоцкий государственный университет