4. Привязка объектов контроля к источникам данных

Работа с типами данных ADO. NET

net есть два рода типов

При работе с типами данных ADO. NET есть два рода типов, с которыми вы можете столкнуться: обобщенные классы данных и классы, специфические для провайдера. Обобщенные реляционные классы данных и интерфейсы реализуют абстрактные конструкции реляционной модели — таблицы, строки, отношения, ограничения — и могут содержать данные, поступающие от разнообразных источников. Эти обобщенные классы данных все входят в пространство имен System. Data, которое является корневым пространством имен для элементов библиотеки классов ADO. NET. Однако чтобы обобщенные классы были полезны, вам обычно требуется возможность подключения к хранилищу данных и выполнения запросов, которые заполняют обобщенные контейнеры или обновляют нижележащее хранилище данных в соответствии с изменениями в контейнерах. Классы, которые вы используете для установки соединения и исполнения запросов, являются классами, специфическими для провайдера, находятся в дочерних пространствах имен System. Data и для разных провайдеров различны. В таблице Г.1 перечислены провайдеры, поставляемые с. NET Framework. Классы управляемых провайдеров должны реализовывать общий набор интерфейсов, определяемых в пространстве имен System. Data. Эти интерфейсы определяют базовые методы и свойства для набора классов, который должен поддерживаться каждым управляемым провайдером. Сюда входят классы для установки соединений с источниками данных, для соз-дания команд, исполняющих запросы, для создания адаптеров, заполняющих наборы данных, и для создания параметров, которые ассоциируются с командой для передачи запросу. В ADO. NET 2.0 имеется также набор абстрактных базовых классов для провайдеров данных в пространстве имен System.Data.ProviderBase, Которые позволяют программировать для различных источников данных безотносительно к провайдеру. Тем самым вы можете переключаться на другой нижележащий источник данных, не изменяя ничего в коде вашего приложения. Данная тема несколько выходит за рамки того, о чем я здесь рассказываю, однако вы должны знать о наличии таких возможностей.

Объектные коллекции, которые в. NET 2.0

типизированные наборы данных значительно выигрывают

Объектные коллекции, которые в.NET 2.0 легко определяются через обобщенные коллекции, принципиально более просты в своем устройстве и обеспечивают лучшую производительность, чем наборы данных. Типизированные наборы данных значительно выигрывают в случае данных небольшого объема, особенно если вам нужна поддержка обновлений, удалений и вставок. Но в случае простого отображения большой коллекции данных вам, при использовании набора данных вместо специальной коллекции, придется заплатить немалую цену в смысле памяти и производительности. Выбор между наборами данных и специальными коллекциями Когда вы имеете дело с очень большими коллекциями данных вроде той, что показана в листинге 6.2, в первую очередь следует принимать во внимание требования к памяти. Исходя из уже виденных вами примеров в этой книге вы, возможно, склонны использовать в качестве коллекции данных типизированный набор. Однако прежде чем сделать это, стоит дважды подумать. Хотя усовершенствованный класс DataSet в.NET 2.0 значительно улучшен в смысле масштабируемости и производительности в случае больших наборов данных, он все-таки остается достаточно громоздким объектом из-за всех встроенных в него возможностей поддержки иерархии, отслеживания изменений и обновления. Если вы рассматриваете представление в сетке миллионов строк данных и собираетесь предоставить пользователям возможность редактировать строки, чтобы при этом набор данных передавал сделанные изменения обратно в хранилище данных, то класс DataSet — это, может быть, действительно то, что вам нужно. Однако я бы не советовал вам проектировать свое приложение таким образом. Отображение больших коллекций данных следует рассматривать как особый случай применения, сфокусированный на представлении — вы лишь позволяете пользователю просмотреть большое число строк, чтобы найти интересующий его элемент данных. Если вам нужно поддерживать редактирование этих элементов данных, я предлагаю предоставить для этого пользователю отдельную форму. Однако как вы скоро увидите, можно позволить ему редактировать значения в сетке, избежав при этом накладных расходов, присущих наборам данных.

Запросы к XML-данным

например вам нужно будет выбрать

Когда ваши данные уже находятся в памяти в документе XML того или ИНОГО Вида , Вам, вероятно, потребуется выполнять к ним запросы, чтобы выбрать некоторое подмножество узлов, содержащихся в документе, на основании некоторого критерия, которому они должны отвечать. Например, вам нужно будет выбрать всех заказчиков из Калифорнии, получить данные по всем поставкам за последние шесть месяцев или выяснить скорость полета ласточки с полной загрузкой. Что бы вы ни хотели отыскать, в. NET для этого имеются простые и мощные способы выполнения запросов к XML-содержанию. Давайте сфокусируем внимание на одной методике запросов, которую поддерживают все типы документов: запросах XPathNavigator. Класс XPathNavigator Является внешним интерфейсом нижележащей машины запросов для любого из типов XML-документов в. NET. В предыдущем разделе вы видели пример, где вызывался метод SelectNodes Объекта XmlDocument. Это упрощенный метод для выбора узлов в действительности просто использует XPathNavigator. Класс XPathNavigator Реализует навигацию в наборе узлов по типу указателя, который вы можете использовать для итерации по документу. Он также экспонирует ряд методов выбора, которые позволяют исполнять запросы к содержимому документа или узла, на который он указывает. Этот раздел посвящен только запросам; следующий немного подробнее рассказывает о навигации. Чтобы получить XPathNavigator Для любого из типов XML-документов, вы вызываете метод CreateNavigator Документа или одного из его узлов. Метод возвращает экземпляр XPathNavigator С указателем, установленным на узел, из которого он был создан. Имея навигатор, вы вызываете один из методов запроса, показанных в таблице Г. 5, чтобы получить XPathNodelterator, Содержащий отвечающие запросу узлы.

Свойство Orders класса Customer

это может быть а может

Свойство Orders Класса Customer Опирается на элемент M Orders , Позволяя непосредственно обращаться ко всем заказам, относящимся к объекту заказчика. Это может быть, а может и не быть разумным в зависимости от того, как должны будут применяться ваши объекты. Если вы собираетесь использовать объекты Customer В различных контекстах, и в некоторых из этих контекстов заказы не будут важны или будут вне области действия, то наличие свойства Orders В классе Customer Можно рассматривать как загрязнение этого класса деталями, которые не всегда имеют отношение к делу. Однако если в вашем приложении имеется ряд случаев применения, где требуется производить итерацию по заказам, относящимся к заказчику, или требуется в целях отображения производить к ним привязку данных, то это, возможно, именно то, что вам нужно. Итак, что касается определений рабочих объектов и привязки данных, вас прежде всего интересуют экспонируемые ими свойства, которые представляют состояние или данные, содержащиеся в логической единице данных. Эти свойства могут представлять объекты с единственным значением, такие, как числа, строки или даты, либо представлять собой ссылки на другие логические единицы, с единственным или со многими значениями. Объект также может экспонировать любое число методов и событий, относящихся к встроенной логике, оперирующей состоянием объекта. Эти методы обычно не участвуют непосредственно в привязке данных этого объекта к UI, но могут так или иначе вовлекаться в нее. Свойства, экспонируемые классом, могут активировать любое число требуемых им функций в своих set-блоках — либо других методов класса, либо даже методов других объектов, которые сохраняются посредством переменных класса. Например, перед тем, как разрешить изменение значения свойства, вы могли бы в его set-блоке вызывать методы, проверяющие устанавливаемое значение по правилам верификации или рабочей логики. Кроме того, другие методы класса могут, вообще говоря, вызываться в любое время из любого места, и эти методы могут потенциально изменять состояние объекта, используемого для привязки данных.

Код конструктора и файлы источников данных

прежде всего следует понять что

Всегда важно понимать, что происходит на за кулисами привязки данных, но особенно это важно в случае, когда генерированный конструктором код делает не совсем то, что вы хотели. Прежде всего следует понять, что все элементы управления и компоненты, создаваемые в результате действий в конструкторе, вместе со всем вспомогательным кодом для настройки объектов привязки и свойств, являются частью автоматически генерируемого стандартного кода Windows Forms. В Visual Studio 2005 этот код размещается в отдельном файле с неполными классами, и этот файл по умолчанию не отображается в дереве проекта Solution Explorer. Чтобы увидеть код, генерированный в результате ваших манипуляций с конструктором, необходимо щелкнуть на значке рядом файлом класса формы в вашем проекте. Ниже вы увидите файл с именем вида <имя фор — мы>.Designer. cs, в котором и содержится весь генерированный конструктором код. Большая часть кода содержится внутри определения метода InitializeComponent. Еще одно действие, происходящее за кулисами, заключается в следующем: всякий раз, когда вы добавляете источник данных в проект извне, используя источники на базе Web-службы или объекта, в проект добавляется файл источника данных, обеспечивающий связь между информацией о типах для объекта или объектов в этом источнике и окном Data Sources Кроме того, если вы настраиваете отображение отдельных компонентов данных на элементы управления, выбирая в выпадающем списке другой тип элемента управления, Visual Studio должна где-то сохранять эту информацию, чтобы вам не пришлось повторять те же настройки в дальнейшем. Информация сохраняется как раз в этих файлах источников данных.