Когда вы создаете объект DataTable, загружая набор данных программно, из XML или из базы данных, типы столбцов специфицируются автоматически, и набор данных может использовать типы столбцов для контроля типов времени выполнения. Однако индексатор класса DataRow, который обеспечивает вам доступ к данным столбцов, представляется просто как ссылка на object. Это означает, что ваш код может попытаться присвоить ему значение любого типа, и у компилятора нет возможности определить, будет такое присваивание успешным или нет. При разработке кода для такой сильно типизированной платформы, как .NET, вы захотите этого избежать. На самом деле вы захотите, чтобы компилятор обнаруживал как можно более случаев несовместимости типов еще на этапе разработки, чтобы поставленный потребителю программный продукт не рухнул внезапно из-за ошибочного приведения или присваивания.

Чтобы сделать набор данных безопасным по типу, нужно, в принципе, поместить его в оболочку API, которая будет специфичной для каждой схемы данных, которую вы реализуете. Это значит, что вам придется написать новый класс со сильной типизацией свойств для всех таблиц и строк (элементов вашей схемы) - и это для каждого используемого набора данных. Шутите! Кто же станет этим заниматься?

Что ж, есть и хорошая новость. Код, который вам необходимо написать, является однозначным преобразованием схемы данных, и потому становится идеальным кандидатом на автоматическую генерацию. Способность генерировать типизированный набор данных для любой желаемой схемы данных встроена в Visual Studio, и вы можете воспользоваться ею, либо запустив инструмент с командной строкой, либо при помощи конструкторов, встроенных в среду Visual Studio.

При использовании Visual Studio 2005 для создания типизированного набора данных на основе конкретной базы генерируется больше, чем просто типизированный набор данных; генерируется также нечто новое, называемое адаптером таблицы, который обеспечивает безопасный в отношении типов способ наполнения набора данными из базы. Вы научитесь работать в этой главе и с типизированными наборами данных, и с адаптерами таблиц, и будете затем использовать эти механизмы для загрузки и обновления данных на протяжении всей статьи.

Вторая проблема, решаемая типизированными наборами данных, смыкается с аспектом безопасности по типу и касается нехорошего стиля программирования, порождаемого нетипизированными наборами данных. Взгляните на код в листинге 2.1.

Если вы считаете, что код следует писать так, что сопровождать его будет легко, то вид жестко закодированных имен столбцов и таблиц и/или индексов, как это сделано здесь, заставит вас нервничать: если схема данных изменится, вам придется выискивать все места, где упомянуты имена таблиц и столбцов. Если же для поиска столбцов в строке вы используете индексы, как это делается в последней строчке кода, то проблема только усугубляется. В лучшем случае вы примените поиск с заменой, что чревато ошибками и требует времени; вы что-то пропустите, и обнаружите проблему лишь во время выполнения. Хорошо еще, если методика вашего тестирования достаточно скрупулезна, чтобы обнаружить проблему на стадии испытаний, зачастую же различия между реальной схемой данных и жестко кодированными именами столбцов или индексов не обнаруживаются вплоть до поставки продукта потребителю.

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