Введение в Microsoft .NET для начинающих (стр. 3 из 3)

Безопасность

Самый важный аспект любой среды разработки распределенных приложений — способ обеспечения безопасности. Благодаря тем из нас, кто долго жаловался, что никто не будет всерьез рассматривать Microsoft в отношении серверных решений для предприятий, пока она полностью не обновит подход к безопасности, в .NET появилось сразу несколько новых концепций. Работа системы безопасности начинается с того момента, когда CLR загружает класс, поскольку загрузчик классов является частью системы безопасности .NET. Так, при загрузке класса в .NET во время выполнения проверяются правила доступа и его внутренняя целостность. Кроме того, в ходе такой проверки выясняется, какая часть кода имеет надлежащие разрешения на доступ к определенным ресурсам. Система безопасности гарантирует проверку предписанных ролей и идентификационных данных. Чтобы не подвергать риску наиболее ответственные данные в распределенных вычислительных средах, эти проверки безопасности не ограничиваются рамками отдельных процессов и машин.

Развертывание

Развертывание — наиболее неприятная процедура разработки крупных распределенных систем. Любой разработчик Windows-программ может сказать, что, столкнувшись с массой разнообразных двоичных файлов, проблемами реестра Windows, компонентами СОМ, установкой библиотек поддержки таких продуктов, как Open Database Connectivity (ODBC) и Data Access Objects (DAO), вы крепко задумаетесь, а правильно ли вы выбрали род занятий. Слава Богу, развертывание — это та часть .NET, над которой проектировщики хорошо потрудились.

Ключ к развертыванию .NET-приложений — концепция сборок (assemblies). Сборкой называют пакет из семантически близких объектов, состоящий из одного или нескольких файлов. Особенности развертывания зависят от того, что вы разрабатываете: Web-серверное приложение или персональное приложение для Windows. Однако с введением сборки как полностью инкапсулированного набора функциональных возможностей развертывание сводится к простому копированию нужных сборок в место назначения.

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

Взаимодействие с неуправляемым кодом

Как вы, наверное, догадались, неуправляемым (unmanaged code) называется код, который не находится под надзором .NET. Поясним: этот код тоже запускается средствами .NET. Однако у неуправляемого кода нет тех преимуществ, которыми обладает управляемый: сбора мусора, унифицированной системы типов и метаданных. Вы спрашиваете, зачем запускать неуправляемый код в среде .NET? Правильно, без особой нужды этого делать не стоит. Однако вы пойдете на это, когда у вас не будет другого выхода. Вот несколько ситуаций, которые показывают, что можно поблагодарить Microsoft за то, что в .NET заложена эта особенность.

Управляемый код, вызывающий функции неуправляемых DLL Допустим, вашему приложению нужно работать с DLL, написанной на С, а компания, создавшая эту библиотеку, пока не адаптировала ее для технологии .NET. В этом случае вам придется по-прежнему вызывать эту DLL из .NET-приложения. Такой пример описан в главе 16.

Управляемый код, использующий компоненты СОМ По той же причине, по какой нужно вызывать из своего .NET-приложения функции из DLL, написанной на С, вам требуется продолжать поддержку компонентов СОМ. Выход в том, чтобы создать .NET-оболочку для компонента СОМ так, чтобы управляемый клиент полагал, будто он работает с .NET-классом. Этот случай также рассматривается в главе 16.

Неуправляемый код, использующий .NET-службы Здесь противоположная проблема: вам нужен доступ к .NET из неуправляемого кода. Она решается с помощью обратного подхода: клиент СОМ вводится в заблуждение, будто он работает с СОМ-сервером, который на самом деле является .NET-службой того же вида. Пример такой ситуации также см. в главе 16.

Подведем итоги

Microsoft .NET — это переход на вычислительную модель, в которой устройства, службы и компьютеры работают совместно, обеспечивая создание решений для пользователей. Центром этого перехода являются разработка .NET Framework и CLR (рис. 2-2). .NET Framework содержит библиотеки классов, совместно используемые различными языками, которые компилируются для запуска в среде CLR. Поскольку С# разработан для CLR, вы не сможете решить даже простейшие задачи без CLR и библиотек классов .NET Framework. Понимание особенностей этих технологий является необходимым условием для получения максимальной пользы от С#, а как этого добиться, вы узнаете из основной части этой книги.

Рис 2.2. В .NET Framework включены библиотеки, предназначенные для облегчения взаимодействия между службами, устройствами и компьютерами.