Лекция 1: Архитектура .NET

Введение в строительные блоки.

Цель этой главы - дать обзор архитектуры .NET Framework, познакомить с новыми технологиями и определить термины, с которыми вы столкнетесь при работе с ней. Также в этой главе изложен процесс построения приложения или компонентов, которые содержат типы (классы, структуры и т. п.), и затем объяснено, как выполняется приложение.

Среда .NET является такой средой, которая была создана для того, чтобы в ней можно было разрабатывать практически любое приложение, с применением С# и

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

До того, как компания Microsoft выпустила язык C# и платформу .NET, разработчики программного обеспечения, создававшие приложения для операционных систем семейства Windows, часто применяли модель программирования СОМ. Технология СОМ (Component Object Model — модель компонентных объектов) позволяла строить библиотеки, которые можно было использовать в различных языках программирования. Например, программист на С++ мог построить библиотеку СОМ, которой мог пользоваться разработчик на Visual Basic. Независимая от языка природа СОМ, безусловно, была удобна. Однако недостатком модели СОМ являлась усложненная инфраструктура, хрупкая модель развертывания и возможность работы только под управлением Windows.

.NET Framework — это программная платформа для построения приложений на базе семейства операционных систем Windows, а также многочисленных операционных систем производства не Microsoft, таких как Mac OS X и различные дистрибутивы Unix и Linux. Для начала ниже приведен краткий перечень некоторых ключевых средств, поддерживаемых .NET.

•Возможность взаимодействия с существующим кодом. Эта возможность, несомненно, является очень полезной, поскольку позволяет комбинировать существующие двоичные компоненты СОМ (т.е. обеспечивать взаимодействие с ними) с более новыми программными компонентами .NET и наоборот. С выходом .NET 4.0 и последующих версий возможность взаимодействия дополнительно упростилась благодаря добавлению ключевого слова dynamic.

•Поддержка многочисленных языков программирования. Приложения .NET можно создавать с использованием любого числа языков программирования (C#, Visual Basic, F# и т.д.).

•Общий исполняющий механизм, разделяемый всеми поддерживающими .NET языками. Одним из аспектов этого механизма является наличие хорошо

определенного набора типов, которые способен понимать каждый поддерживающий .NET язык.

•Языковая интеграция. В .NET поддерживается межъязыковое наследование, межъязыковая обработка исключений и межъязыковая отладка кода. Например, базовый класс может быть определен в C#, а затем расширен в Visual Basic.

•Обширная библиотека базовых классов. Эта библиотека позволяет избегать сложностей, связанных с выполнением низкоуровневых обращений к API - интерфейсам, и предлагает согласованную объектную модель, используемую всеми поддерживающими .NET языками.

•Упрощенная модель развертывания. В отличие от СОМ, библиотеки .NET не регистрируются в системном реестре. Более того, платформа .NET позволяет сосуществовать на одном и том же компьютере нескольким версиям одной и той же сборки *.dll.

Dynamic Link Library— «библиотека динамической компоновки», динамическая библиотека, позволяющая многократное использование различными программными приложениями. Первоначально предполагалось, что введение DLL позволит эффективно организовать память и дисковое пространство, используя только один экземпляр библиотечного модуля для различных приложений. Замена DLL - программ с одной версии на другую должна была позволить независимо наращивать систему, не затрагивая приложений. В дальнейшем идея модульности выросла в концепции COM. DLL hell возникает, когда несколько приложений требуют одновременно различные, не полностью совместимые, версии библиотек, что приводит к сбоям в этих приложениях и к конфликтам типа, DLL hell, резко снижая общую надёжность операционных систем.

CLR (Common Language Runtime) - автоматическое обнаружение, загрузка и управление объектами .NET, ряд низкоуровневых деталей, таких как управление памятью, размещение приложения, координирование потоков и выполнение проверок, связанных с безопасностью.

CTS (Common Type System) - описание всех возможных типов данных и всех программных конструкций, поддерживаемых исполняющей средой. Кроме того, в CTS показано, как эти сущности могут взаимодействовать друг с другом, и указано, как они представлены в формате метаданных .NET. Важно понимать, что отдельно взятый язык, совместимый с .NET, может не поддерживать абсолютно все функциональные средства, определенные спецификацией CTS, поэтому существует общеязыковая спецификация.

CLS (Common Language System) - спецификация, в которой описано подмножество общих типов и программных конструкций, которое должны поддерживать все языки программирования для .NET. Таким образом, если создаваемые типы .NET предлагают только средства, совместимые с CLS, ими могут пользоваться все языки, поддерживающие .NET.

Основной механизм CLR физически имеет вид библиотеки по имени mscoree.dll, также известной как общий механизм выполнения исполняемого кода объектов

(Common Object Runtime Execution Engine). Когда на сборку производится ссылка с

целью ее использования, библиотека mscoree.dll загружается автоматически и, в свою очередь, загружает требуемую сборку в память. Исполняющая среда отвечает за решение множества задач. Первая и наиглавнейшая задача — определение местоположения сборки и нахождение запрошенного типа в двоичном файле за счет чтения содержащихся в нем метаданных. Затем CLR размещает тип в памяти, преобразует связанный с ним CIL - код в специфичные для платформы инструкции, производит все необходимые проверки безопасности и после этого выполняет нужный код.

Исходный код программы может быть написан на любом языке, поддерживающем среду выполнения CLR. Затем соответствующий компилятор проверяет синтаксис и анализирует исходный код программы, результатом компиляции будет являться управляемый модуль (managed module) — стандартный переносимый исполняемый файл, который требует для своего выполнения CLR.

Компиляторы машинного кода производят код, ориентированный на конкретную процессорную архитектуру, например х86, х64. В отличие от этого, все СLR - совместимые компиляторы генерируют IL — код.

Каждый компилятор, предназначенный для CLR, помимо генерации IL - кода, должен также создавать полные метаданные (metadata) для каждого управляемого модуля. Если выражаться кратко, то метаданные - это набор таблиц данных, описывающих то, что определено в модуле, например типы и их члены. В метаданных также есть таблицы, указывающие, на что ссылается управляемый модуль, например на импортируемые типы и их члены. Метаданные расширяют возможности таких старых технологий, как библиотеки СОМ-типов и файлы языка описания интерфейсов, устраняют необходимость в заголовочных и библиотечных файлах при компиляции, так как все сведения о типах/членах, на которые есть ссылки, содержатся в файле с реализующим их IL - кодом. Компиляторы могут читать метаданные прямо из управляемых модулей.