Главная » Microsoft SQL Server, Базы данных » Развертывание пользовательских типов интеграции CLR

0

Существуют по крайней мере три способа работы с пользовательскими типами в среде разработки. Во время создания и тестирования функциональных единиц может использоваться интерфейс Visual Studio 2005, в котором будут выполняться инструкции T-SQL DDL и запросы, предназначенные для тестирования пользовательских типов. Как только новый тип будет готов для использования другими разработчиками в таблицах и серверном программном коде (например, в таблицах и представлениях Т-SQL или в процедурах, функциях, триггерах и консолидациях CLR или Т-SQL), его сборка может быть развернута в локальной папке каждой клиентской утилиты, в которой будет использована для разработки. Когда пользовательский тип готов к применению в среде разработки, он может быть развернут в глобальном кэше сборки или в рабочем пространстве всех клиентских приложений, которые будут ссылаться на новый тип.

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

Например, по умолчанию утилита Management Studio будет искать файлы . dll в каталоге:

c:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE

Помещение файла .dll в этот каталог обеспечит возможность установки ссылок на данный пользовательский тип в запросах, выполняемых в среде утилиты Management Studio. Неуправляемые подключения OLE DB, такие как утилита SQLDMD, а также подключения ODBC, такие как утилита osdl, распознают экземпляры пользовательского типа только как двоичные данные.

В общем случае для использования пользовательского типа данных необходимо наличие разрешения SQL Server REFERENCES. Если пользовательский тип используется в процедуре, функции или триггере Т-SQL или интеграции CLR в качестве локальной переменной, также необходимо наличие разрешения EXECUTE.

Строго именованные сборки и глобальный кэш сборки

Приложения, которые ссылаются на конкретную сборку, будут стремиться использовать ее, точно идентифицируя по имени, версии и подписи. Если сборка не использует строгое имя, приложение может не волноваться о ее версии. Это усложняет процесс развертывания сборок, так как велика вероятность потери обновления в некоторых местах архитектуры, ориентированной на службы. В результате этого сборка, существующая в базе данных, не будет приведена в соответствие со сборками, на которые ссылаются службы узлов. Пока ссылки из приложения .NET на общедоступную структуру и имя соответствуют имени и структуре типа в базе данных, приложение может оперировать типом так, будто оно имеет полные и точные знания о типе, содержащиеся в базе данных. Это так похоже на ад динамических библиотек .dll, который была призвана преодолеть среда .NET Framework 2.0.

В то время как реверсная инженерия и дизассемблирование всегда несли с собой потенциальный риск во всех языках программирования и на всех платформах, среда .NET Framework предлагает надежную утилиту дизассемблирования кода MSIL. К счастью, модель системы безопасности среды .NET Framework не предполагает, что сокрытие кода от внешних представлений будет необходимой ее составляющей. Подпись и аутентификация являются ключевыми компонентами защиты сборок .NET. Сборки могут быть подписаны сильно защищенным ключом, предотвращающим возможность введения в нее компонентов, которые могут подвергнуть риску все приложение. Такие сборки могут ссылаться только на те сборки (не считая, естественно, пространства имен System), которые подписаны той же парой ключей. Подписи необходимы для всех сборок, помещаемых в GAC.

Компания Microsoft рекомендует при совместном использовании некоторой сборки несколькими приложениями на одном компьютере помещать эти сборки в GAC. В этом случае гораздо легче дать гарантию того, что сборка закрыта в кэше от всех, кроме администратора. Из кэша GAC также можно параллельно запустить несколько версий одной и той же сборки. И наоборот, если хотя бы одна сборка в приложении помещена в GAC, то развертывание приложения усложняется необходимостью использования Windows Installer 2.0 или утилиты Global Assembly Cache Tool для перемещения сборки в кэш GAC всех узлов приложений, которые будут использовать данный пользовательский тип. Сборки, развернутые вместе с приложением в папке приложения, могут быть перемещены в GAC с использованием основанного на команде хсору продвижения и тактики откачки. К тому же, если сборки не развернуты в глобальном кэше GAC, разработчику придется самому заботиться о том, какие сборки принадлежат его приложению. При принятии решения относительно того, где развертывать сборки: в глобальном кэше GAC или в папке приложения, следует основательно изучить требования организации к системе безопасности.

Создание строго именованных сборок .NET

При работе с пользовательскими типами, которые должны быть развернуты в GAC, исключительно важно четко понимать порядок создания строго именованных сборок. Существуют три аспекта строгого именования: идентификатор сборки, открытый и секретный ключи. Секретный ключ еще иногда называют цифровой подписью. Все аспекты строгого именования управляются с использованием Visual Studio 2005.

Идентификатор сборки можно увидеть и изменить во вкладке Application окна Project Designer (рис. 29.1), которое открывается с помощью команды меню Projects<имя проекта> properties или аналогичной команды контекстного меню (открываемого щелчком правой кнопкой мыши на имени проекта в Solution Explorer).

Пара ключей, необходимая для завершения формирования строгого имени, может быть сгенерирована с помощью утилиты Strong Name Tool (sn. exe). Доступ к этой утилите открыт в окне командной строки программы Visual Studio. Эта утилита имеет массу функций. Как и во всех утилитах командной строки, полную справку по ней можно получить, набрав в строке запроса sn /?.

На рис. 29.2 показаны команды создания пары открытого и секретного ключей и развертывания ключа в папке решения проекта.

Рис. 29.1. Идентификатор сборки. В его формировании участвует информация о названии и версии, а также региональные настройки (такие, как язык)

Puc. 29.2. Создание пары открытого и секретного ключей, используемых для создания строгого имени сборки.

Данный пример создан в 64-разрядной операционной системе, однако та же процедура используется и в 32-разрядных системах

После развертывания ключа в папке проекта включить его в сборку можно в окне Project Designer (рис. 29.3).

Информация о строгом имени сборки будет включена в ее манифест. Для добавления ключа е сборку можно использовать специальную утилиту командной строки Assembly Linker (al. ехе). Эта утилита выполняет ту же работу, что и вкладка Signing окна Project Designer, однако она требует передачи в качестве аргумента имени файла .dll сборки. Окно Project Designer, с точки зрения пользователя, является более дружественным. Работа с файлом .dll предполагает, что пользователь не может использовать функцию Deploy программы Visual Studio в процессе разработки.

Для определения файла ключа можно также использовать и внутренние атрибуты сборки, например:

<Assembly:AssemblyKeyFileAttribute("SQLServerBible_keypair.snk")>

Политика безопасности организации может потребовать использования и более сложной реализации строгого имени. Например, может быть принято решение не отдавать цифровую подпись (т.е. секретный ключ) разработчикам. В такой ситуации разработка и тестирование

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

Рис. 29.3. Добавление ключа в сборку в окне Project Designer

Обслуживание пользовательских типов

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

Резюме

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

Несомненно, компания Microsoft встретит большое сопротивление пользователей, когда в следующих версиях удалит старые пользовательские типы из SQL Server, несмотря на то, что в Books Online существует предупреждение на этот счет. Равновероятно, что сопротивление пользователей помешает быстрому внедрению типов интеграции CLR. Любая новая технология вначале должна быть ассимилирована. Также существует потребность в совершенно ином подходе к контролю над изменениями, по мере того, как мышление разработчиков будет смещаться в сторону изолированных архитектур, ориентированных на службы. Изолированные системы и интеграция CLR усложнили традиционный цикл разработки приложений, и в нем сообщество пользователей SQL Server еще не накопило достаточного опыта.

В некоторый момент появятся удобные стратегии миграции и внесения изменений. По мере эволюции архитекторы данных и разработчики осознают значение малых объектов в базах данных. И — примите это как предсказание — компания Microsoft ответит на давление пользователей и расширит возможности так, чтобы размер объектов базы данных преодолел роковой барьер в 8 Кбайт. Вам не кажется, что когда-то вы это уже слышали?

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

Источник: Нильсен, Пол. Microsoft SQL Server 2005. Библия пользователя. : Пер. с англ. — М. : ООО “И.Д. Вильямс”, 2008. — 1232 с. : ил. — Парал. тит. англ.

По теме:

  • Комментарии