Главная » Microsoft SQL Server, Базы данных » Беглое знакомство со средой .NET Framework

0

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

Приложения, связанные со средой .NET Framework, создаются согласно стандартным ориентированным на службы протоколам (SOA). Так, XML позволяет установить соединение с компонентами других приложений, как ориентированных на .NET, так и других, или даже запускаемых в блоках Windows.

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

Среда .NET Framework должна была стать реализацией ранее невыполненных обещаний компании Microsoft в отношении масштабируемости и увеличения производительности Windows, хотя в версии 2.0 производительность остается ограниченной интересами возможности взаимодействия сетей и интеграции между приложениями Microsoft. В данной версии было взято за цель достижение производительности таких существующих интерфейсов программирования, как СОМ и OLE DB. В целом этот план был выполнен и даже перевыполнен. В будущих версиях можно небезосновательно ожидать дополнительных значительных прорывов в производительности.

Среда .NET Framework доступна в операционных системах Windows 2000, Windows 2003, Windows ХР, Windows СЕ и Windows Vista; также она будет доступна во всех будущих версиях этой операционной системы. Гибкая система поддержки версий позволяет различным сборкам базовых библиотек классов .NET Framework быть доступными разным приложениям, одновременно запущенным на одном компьютере. Основной задачей здесь было преодоление жесткости в предыдущих моделях регистрации библиотек . dll, до боли знакомой многим разработчикам.

Сборки

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

Процесс компиляции приложений .NET разделен на два этапа. Сборки хранятся на промежуточном языке MSIL (Microsoft Intermediate Language). На каком бы языке .NET программист ни написал программу, она будет скомпилирована в MSIL и сохранена в сборке. В целом генерируемый код MSIL идентичен, независимо от того, на каком языке изначально была написана программа.

Во время выполнения сборки MSIL преобразуются в машинные инструкции компилятором JIT (Just In Time) интерпретатора CLR и загружаются в память. Интерпретатор CLR знает, когда именно MSEL нужно преобразовать в машинный код, стремясь перемещать в память команды только по мере необходимости и удаляя их из памяти, когда потребность в них отпала. Последнюю операцию часто называют уборкой мусора.

Все типы проверяются компилятором JIT во время выполнения программы. Остальные вопросы защиты, такие как сертификаты, подписи, политики и т.п., также решаются во время выполнения программы. На этом основана магия переносимости среды .NET Framework. Если операционная система понимает MSIL и файлам разрешено запускаться на локальном компьютере, то приложение будет выполнено.

Основными компонентами среды .NET Framework являются типы. Типом может быть значение или ссылка. Типы значений обладают следующими характеристиками:

?               включают примитивы, такие как integer, char или boolean;

?               обслуживаются в стеке выполнения программы;

?               не могут содержать поля, методы или свойства;

?               однозначно назначены переменным.

Типы ссылок имеют следующие характеристики:

И содержат объекты, такие как классы, интерфейсы, делегирования, массивы и перечисления;

?               обслуживаются в куче управляемых объектов, отделенной от стека выполнения;

?               могут содержать поля, методы и свойства;

?               совместно используются всеми переменными, назначенными данному типу.

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

Только типы, соответствующие спецификации CTS (Common Type System) среды .NET, могут загружаться и обрабатываться интерпретатором CLR. Эти типы принято называть управляемыми. В соответствии с архитектурой среды .NET Framework все языки программирования, согласующиеся с CTS, должны генерировать идентичные управляемые типы. На практике существуют некоторые отличия между разными языками .NET. Среда .NET Framework реализует общеязыковую спецификацию CLS (Common Language Specification), чтобы устранить различия между языками программирования. За удовлетворение требований спецификации CLS несут совместную ответственность и программист, и компилятор. Только если код является CLS-совместимым, сгенерированный код MSIL будет доступен всем остальным приложениям, которые также генерируют управляемые типы. Следует отметить, что для запуска в интерпретаторе CLR необходимыми компонентами являются CTS- и (не обязательно) CLS-совместимость. CLS-совместимость всего лишь гарантирует то, что данная сборка может быть корректно использована компонентами, написанными на других языках программирования. К тому же CLS-совместимыми должны быть только типы и члены компонентов, предлагаемые для общего использования.

Спецификацию CTS, включая CLS, можно найти в документации .NET Frame- Совет                       work SDK, входящей в состав документации Visual Studio 2005, а также на Web-

сайте компании Microsoft.

Основной единицей компиляции, распределения, повторного использования, отслеживания версий и защиты является сборка. В терминогогии объектно-ориентированного программирования (ООП) сборку можно рассматривать как границы инкапсуляции, а среда .NET Framework является объектно-ориентированной. Сборка содержит исполняемый программный код в виде MSIL и все метаданные ресурсов для одного или нескольких типов. Большая часть метаданных содержит информацию о типах, содержащихся в сборке. Каждая сборка также содержит манифест метаданных. Этот манифест содержит дружественное имя и атрибуты, которые обобщают строгое имя сборки, назначенное ей при создании. Манифест также содержит все ссылки сборки, т.е. список всех сборок, зависимых от нее. На основании манифеста сборки компилятор JIT может по мере необходимости эффективно преобразовать код MSIL в машинные команды.

Домены приложений

Основной единицей пространства памяти запущенного приложения .NET является домен приложения. Теоретически приложение .NET может открывать сборки либо во время компиляции, либо во время работы приложения (примерно аналогично раннему и позднему связыванию ActiveX). На практике же без твердого понимания многоуровневых методов подстановок, используемых для переноса сборок в домен приложения, такой режим работы может показаться несколько странным.

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

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

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

Удаленность можно рассматривать как версию .NET технологии DCOM. Разра- Внимание! ботчики могут действительно захотеть воспользоваться этими возможностями, чтобы избежать необходимости включения явных ссылок в манифестах на пользовательские типы, определенные в сборках уровня приложения SQL Server. Только в очень редких случаях удаленность используется для создания ссылок на типы внутри процесса SQL Server, так как в этом случае решение становится слишком сложным и по определению раскрывает SQL Server. Такой подход вряд ли сможет оправдать связанные с ним риски и усилия программиста.

Приложение, содержащее только управляемые типы и использующее среду .NET Framework, принято называть управляемым кодом. Управляемый код отличается от неуправляемого тем, что среда выполнения CLR абстрагирована от аппаратного обеспечения и операционной системы. Программист может обойти этот защищенный режим выполнения программы, особенно учитывая накопившийся объем обычного кода, который было бы непрактично переписывать немедленно (или когда-нибудь) в управляемый код .NET. Например, на неуправляемые компоненты СОМ можно ссылаться, используя систему, предлагаемую сборкой периферийного интерфейса адаптера (PIA). Также можно выполнить функции любой отличной от СОМ библиотеки, используя механизм инициации платформы.

Программист на C++ (и, до определенного уровня, на С#) может выделять память и использовать указатели для ссылок на область памяти. К сожалению, эта возможность обхода требований безопасности типов приоткрывает лазейки для создания приложений, которые смогут повредить операционную среду. Хотя бы только по этой причине одним из наиболее важных действий в обеспечении защиты SQL Server является построение и развертывание на сервере баз данных лишь CLS-совместимых сборок.

Дополнительная Дополнительную информацию о сборках периферийных интерфейсов адапте- информация ров вы найдете в главе 30.

Совершенно очевидно, что программный код .NET может существовать отдельно от приложения, которое его использует. Эти реалии открывают хорошую возможность осветить новый тип защиты, встроенный в CLR, — безопасный доступ к коду (CAS). С AS гарантирует, что весь управляемый код для доступа к типам использует безопасные методы. Подобно CLS, проверка безопасности типов возлагается на компилятор. В то же время написание прягодного к проверке С AS-совместимого кода вменяется в обязанность программисту. С AS реализует синтаксис защиты; разработчик может декларативно устанавливать свойства разрешений или императивно создавать объекты разрешений.

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

Очень важно, чтобы программист при создании приложения учитывал требования CAS, в противном случае это может привести к сбою работы сервера. К счастью, интеграция CLR в SQL Server проверяет, является ли запускаемый в нем код CAS-совместимым. Среда выполнения CLR в SQL Server предоставляет разработчику частичные классы, которые за кулисами комбинируются с другим кодом для создания компонентов баз данных CLR. В части класса, которой пользователь не может манипулировать, содержатся некоторые важные CAS-совместимые инструкции защиты.

Когда JIT компилирует программный код в SQL Server, он проверяет соответствие требованиям С AS, безопасность типов, а также разрешения SQL Server. Когда программируется .NET-компонент базы данных, он может маркироваться как SAFE, EXTERNAL ACCESS или UNSAFE. Это определяет используемые ограничения модели программирования, а также объявления и императивы С AS, которые будут использованы этой сборкой.

Для построения CLS-совместимых сборок разработчик должен твердо придерживаться правил, изложенных в документе Common Language Infrastructure, Partition I: Concepts and Architecture, который можно найти в папке Tool Development Guide, устанавливаемой вместе с Microsoft .NET Framework SDK. Даже если разработчик строго следует спецификации, CLS-совместимому компилятору также необходимо гарантировать совместимость сборки с CLS. Все компиляторы пакета Visual Studio 2005 гарантируют такую совместимость. CLS-совместимость должна рассматриваться как обязательное требование для компонентов интеграции CLR, хотя бы потому, что нет иного способа задействовать языки, которым предстоит работать с конкретным объектом базы данных. В качестве одного из вариантов практически безболезненного обеспечения CLS-совместимости можно рассмотреть создание интегрированных в базу данных объектов CLR с помощью языка VB.NET в среде Visual Studio 2005.

Почему VB.NET является лучшим выбором для обеспечения CLS-совместимости? Ведь компиляторы C++ и C# в Visual Studio 2005 также способны создавать CLS-совместимый код, равно как и компилятор VB. Разработчикам, слабо знакомым с программированием в среде .NET Framework, VB.NET окажет наибольшую помощь в написании CLS-совместимого программного кода. VB.NET по праву считается самым простым в использовании языком семейства .NET, предназначенным для использования в среде быстрой разработки приложений (RAD). Образно говоря, VB.NET предлагает только CLS-совместимые инструкции. Естественно, выбор исключительно за вами; и если вы хорошо знакомы с каким- либо другим управляемым языком, естественно, лучше использовать его. Если же вы только начинаете программировать в среде .NET Framework или работаете преимущественно в среде быстрой разработки приложений, серьезно подумайте о разработке компонентов базы данных на языке VB.NET.

Что делает Visual Studio лучшим выбором для компиляции приложений? Ответ заключается в наличии множества дополнительных функций, которые предлагает эта программа. Такой же компилятор VB.NET входит в состав .NET Framework SDK, так что технически возможно создавать программный код даже в простом текстовом редакторе, таком как Notepad, а затем скомпилировать его в командной строке и получить полностью CLS-совместимые файлы MSEL. Некоторые даже могут аргументировать этот подход тем, что прежде чем переходить к такому элегантному инструменту, как Visual Studio, нужно понять, как все работает на самом нижнем уровне.

Может быть, в вышеописанном подходе и есть разумное зерно с точки зрения учебного процесса, но лично я считаю, что нет никакого смысла бороться с невооруженным специальными средствами текстовым редактором или компилятором командной строки. Максимальную пользу и качество программного кода вы получите, используя Visual Studio. Может, вы почувствуете больший контакт с языком программирования, используя напрямую SDK, но практически наверняка те, кто сразу связал свою судьбу с Visual Studio, развернут свой первый успешный .NET- компонент базы данных гораздо раньше тех, кто начал с SDK. Для большинства начинающих программистов знакомства с основными концепциями среды .NET более чем достаточно, и совершенно не нужно создавать себе лишние сложности, связываясь с SDK. Как вы вскоре увидите, средства Visual Studio 2005 сами докажут, что эта программа является наилучшим выбором. Перед тем как более внимательно взглянуть на инструменты, используемые для создания типов интеграции CLR, посмотрим, какими же могут быть эти типы.

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

По теме:

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