1. Построение приложений с привязанными данными в Windows Forms

Простая привязка данных с помощью источников привязки

рассмотрим простой класс формы приведенный

Простейший способ применения источника привязки состоит в том, чтобы использовать его в качестве посредника между данными и элементами управления, которые эти данные отображают. Рассмотрим простой класс формы, приведенный Эта форма содержит единственную сетку с именем m Grid, в чьем свойстве Dock установлено значение Fill, благодаря чему сетка автоматически заполняет собой всю форму. Класс содержит также в качестве элемента компонент источника привязки, к которому привязана сетка. Все это можно смонтировать в конструкторе, что обычно делается перетаскиванием сетки и источника привязки на форму и установкой их свойств в конструкторе. Однако пока давайте посмотрим, как все это делается без трюков с конструктором. Код в обработчике события для загрузки формы извлекает данные Customers через адаптер таблицы, а затем устанавливает свойство DataSource Источника привязки на таблицу Customers. Поскольку свойство сетки DataSource Уже было установлено в конструкторе на источник привязки, для загрузки и отображения данных Customers в сетке больше ничего не требуется. Когда вы выполняете привязку к таблице в составе набора данных, будь он сильно типизированным или нет, вы в действительности имеете дело с псевдотаблицей по умолчанию для этой таблицы. Каждая таблица имеет псевдотаблицу по умолчанию , И именно она используется в привязке данных.

Вы можете явным образом конструировать псевдотаблицу для таблицы данных и привязаться к ней, что позволяет гибко фильтровать или сортировать псевдотаблицу в целях изменения представления данных. В качестве альтернативы можно фильтровать и сортировать данные посредством источника привязки, при условии, что исходная коллекция данных реализует интерфейс IBindingList.

Определение и использование привязанных к данным рабочих объектов

i что i такое бизнес

Масса людей возражает против термина «бизнес-объект». Что такое бизнес-объект? Если ваше приложение — игра, являются ли ваши объекты действительно бизнес-объектами? Скорее всего нет. Но для целей этой книги полезно иметь общий термин, обозначающий «те объекты, входящие в ваше приложение, которые не относятся ни к представлению, ни к доступу к данным; которые обычно имеют некоторую встроенную логику, правила, верификацию или поток исполнения; могут сами содержать данные; наконец, которые существуют где-то между тем, что пользователь видит на экране, и кодом, исполняющим запросы к вашему хранилищу данных». Поэтому я буду пользоваться термином «бизнес-объект», а вы при желании можете всякий раз про себя подставлять это более развернутое определение.

Рабочие объекты появляются во многих формах. Некоторые могут быть чистыми контейнерами данных, другие могут просто содержать логику — код, манипулирующий данными, поступающими откуда-то извне, — а некоторые могут быть комбинацией того и другого. Что касается представления данных в приложениях Windows, некоторые рабочие объекты могут содержать данные, и вы можете использовать такой объект непосредственно для представления этих данных. В этом случае хотелось бы использовать их таким же образом, как вы используете набор данных — устанавливаете источник данных на коллекцию этих объектов или единственный экземпляр, а дальнейшую работу предоставляете элементу управления.

Осуществление такой привязки данных в. NET 2.0 довольно просто. Как говорилось в предыдущих главах, вся привязка данных в Windows Forms основана на наборе интерфейсов, которые определяют различные возможности объектов и коллекций в контексте доступа и навигации по данным. Пока объекты, используемые для привязки данных, поддерживают соответствующие интерфейсы, привязанные к данным элементы управления не будут замечать, что они работают со специальными объектами, а не с внутренними реляционными объектами данных. NET Framework. Пока класс Customer Является простым сильно типизированным контейнером для значений данных, относящихся к некоторой рабочей единице. Каждое из этих значений является примитивом. NET; на самом деле это простейший тип примитивов для привязки данных — строки. Если бы так было со всеми рабочими объектами, все было бы просто. Но дело в том

Программное добавление столбцов

прежде всего нужно определить столбцы

Существуют различные способы программного добавления к сетке столбцов и строк. Прежде всего нужно определить столбцы, из которых будет составлена сетка. Для определения столбца вы должны специфицировать шаблон ячейки, по которому будет строиться столбец. Шаблон ячейки будет по умолчанию использоваться для ячеек в данном столбце, когда к сетке добавляется строка. Шаблоны ячеек являются экземплярами производных от DataGridViewCell Классов. Для представления столбцов из текстовых полей, кнопок, комбинированных полей, гиперссылок и изображений вы можете воспользоваться встроенными типами ячеек. NET. Еще один встроенный тип ячейки представляет заголовки столбцов в сетке. Для каждого из типов ячеек имеется соответствующий тип столбца, предназначенный для хранения ячеек такого типа. Вы можете конструировать экземпляры DataGridViewColumn, В которых тип ячейки представлен как шаблон, но, как правило, вы создаете экземпляр столбца производного типа, предназначенного для конкретного типа ячеек, с которым вы хотите работать. Кроме того, вы можете определять свои собственные специальные типы ячеек и столбцов.

Пока давайте ограничимся самым распространенным и простым типом ячейки, ячейкой текстового поля DataGridViewTextBoxCell. Это, кстати, тип ячейки по умолчанию. Добавить программно столбец текстовых полей можно одним из трех способов. Воспользуйтесь перегруженной версией метода Add Коллекции Columns Сетки: добавляете столбцы подобным образом, значения их имен и заголовков по умолчанию нулевые. Чтобы установить эти или другие свойства экземпляра столбца, вы можете обращаться к ним как до, так и после добавления столбца к коллекции Columns. Вы можете также воспользоваться индексацией коллекции Columns И получить ссылку на столбец, после чего использовать эту ссылку для доступа к любым свойствам столбца.

Привязка ведущий-детализация

вы уже видели простой пример

Привязка к данным «ведущий-детализация» сильно отличается от того, как это делается в WindowsForms. Вы уже видели простой пример в листинге А.8. Для каждого привязанного элемента управления, который будет участвовать в представлении ведущий-детализация, вы устанавливаете отдельный управляющий элемент источника данных. Первый источник данных обычным образом привязывается к родительской коллекции данных. Если дочерним источником является SqlDataSource, В его свойстве SelectCommand Устанавливается соответствующий запрос для получения дочерней коллекции данных. Затем вы по выбору можете либо предусмотреть параметризованное предложение Where, Либо установить в свойстве FilterExpression Элемента управления источника допустимый критерий фильтрации, снабдив его любыми необходимыми параметрами в FilterPa — Rameters. Пример такого подхода показан в листинге А.9. В этом примере сетка заказчиков привязана к SqlDataSource Тем же способом, что был показан в предыдущих примерах. Сетка заказов привязана к своему собственному источнику данных, запрос которого выбирает из таблицы Orders все записи заказов. Затем в свойстве FilterExpression Источника устанавливается строка с заместителем. Заместитель заполняется из параметра фильтра, который предоставляется объектом ControlParameter. Этот объект извлекает значение, которое будет использоваться для фильтрации, из некоторого другого элемента управления на странице, в данном случае из сетки заказчиков, по указанному имени свойства этого элемента управления . В результате на Web-страницу поступают все записи заказов, но в действительности на отображаемые данные наложен фильтр, отбирающий записи, которые будут переданы через источник данных.

Верификация в Windows Forms

примеры верификации включают в себя

Вся верификация сводится к проверке ввода пользователя, чтобы убедиться в его действительности, исходя из некоторых критериев, которые вы, как разработчик приложения, установили. Примеры верификации включают в себя В большом приложении верификация может и должна происходить на нескольких уровнях. Первой линией обороны является проверка ввода, поступающего от пользователей, в той точке, куда они его подают — на уровне формы и элементов управления. Однако в больших приложениях данные часто передаются вниз на рабочий уровень и/или уровень доступа к данным посредством некоторой технологии удаленного доступа, такой, как Web-служба. Может существовать сколько угодно вмешивающегося в этот процесс кода, через который они должны пройти, прежде чем будут зафиксированы в хранилище данных. Верификация данных должна происходить, когда пользователь вводит данные, но также должна происходить при пересечении границ, например, при передаче данных от приложения развитого клиента в средний ярус, предоставляющий рабочие службы для этого приложения.

Сколько будет встроено интеллекта в приложение яруса представления, определяется проектом, но вообще в многоуровневой архитектуре приложения желательно делать уровень или ярус представления сколь возможно более легким. Вам желательно привязать верификацию, которая относительно инвариантна, к уровню формы, но более сложные проверки, которые могут изменяться со временем, переложить на рабочий уровень. Вне зависимости от того, какой объем логики верификации вы располагаете на уровне форм, в элементы управления и формы Windows встроена развитая инфрастуктура, позволяющая вам производить необходимые проверки, когда это потребуется.