Главным недостатком VB6 (который был устранен в Visual Basic .NET) является то, что VB6 является, скорее, "объектно-осведомленным" языком, а не полноценным объектно-ориентированным. Например, в VB6 программисту не позволяется связывать типы отношениями "подчиненности" (т.е. нет классического наследования) и нет внутренней поддержки конструкции параметризованных классов. Кроме того, VB6 не дает возможности строить многопоточные приложения, если только вы не готовы "спуститься" до низкоуровневых вызовов Win32 API (что в лучшем случае достаточно сложно, а в худшем – опасно).
Было предложено использовать Java. Язык программирования Java является (почти) полностью объектно-ориентированным и имеет синтаксические корни в C++. Многие знают, что поддержка межплатформенной независимости – далеко не единственное преимущество Java. Java (как язык) избавлен от многих синтаксических несообразностей C++. Java (как платформа) предлагает программисту большое число встроенных "пакетов", содержащих различные определения типов. С помощью этих типов, используя "только Java", можно строить приложения, предлагающие сложный интерфейс пользователя, обеспечивающие связь с базами данных, обмен сообщениями или работу клиента в Web.
Хотя Java – очень элегантный язык, его потенциальной проблемой является то, что использование Java в цикле разработки обычно означает необходимость использования Java и для взаимодействия клиента с сервером. Как следствие, Java не позволяет возлагать большой надежды на возможности языковой интеграции, так как это идет вразрез с декларируемой целью Java (единый язык программирования для всех задач). Реальность, однако, такова, что в мире существуют миллионы строк программного кода, которым бы идеально подошло взаимодействие с более новым программным кодом. К сожалению, Java делает эту задачу проблематичной.
Java в чистом виде просто не подходит для многих приложений, интенсивно использующих графику или сложные вычисления (в этих случаях скорость работы Java оставляет желать лучшего). Для таких программ в соответствующем месте выгоднее использовать язык более низкого уровня (например, C++). Увы, пока Java не обеспечивает более широкие возможности доступа к "чужеродным" API, истинная интеграция различных языков оказывается практически невозможной.
Модель COM (Component Object Model – модель компонентных объектов) была предыдущим каркасом разработки приложений Microsoft. По сути, COM – это архитектура, "заявившая" следующее: если класс будет построен в соответствии с правилами COM, то получится блок двоичного кода многократного использования.
Прелесть двоичного COM-сервера в том, что способ доступа к нему не зависит от языка. Поэтому программисты, использующие C++, могут строить COM-классы, пригодные для использования в VB6. Программисты, применяющие Delphi, могут использовать COM-классы, построенные с помощью C, и т.д. Однако, и вы, возможно, об этом знаете, независимость COM от языка несколько ограничена. Например, нет возможности получить новый COM-класс из уже существующего (поскольку COM не предлагает поддержки классического наследования). Вместо этого для использования типов COM-класса вам придется указать несколько неуклюжее отношение "обладания".
Еще одним преимуществом COM является прозрачность дислокации. Используя такие конструкции, как идентификаторы приложения (AppID), "заглушки" и "заместители" в среде выполнения COM, программист может избежать необходимости непосредственного обращения к сокетам, RPC-вызовам и другими низкоуровневым элементам. Рассмотрим, например, следующий программный код VB6 COM-клиента.
' Этот блок программного кода VB6 может активизировать COM-класс,
' созданный на любом языке, поддерживающем COM, и размещенный
' в любой точке сети (включая вашу локальную машину).
Dim с as MyCOMClass
Set с = New MyCOMClass ' Размещение выясняется с помощью AppID.
с.DoSomeWork
Хотя COM можно считать очень успешной объектной моделью, внутренне она чрезвычайно сложна (по крайней мере, пока вы не потратите несколько месяцев на изучение ее внутренних механизмов – особенно если вы программируете на C++). С целью упрощения процесса разработки бинарных COM-объектов было создано множество каркасов разработки приложений с поддержкой COM. Среди них, например, библиотека ATL (Active Template Library – библиотека активных шаблонов), которая обеспечивает еще одно множество C++-классов, шаблонов и макросов, упрощающих создание COM-типов.
Многие другие языки также в значительной степени скрывают инфраструктуру COM от глаз программиста. Однако поддержки самого языка оказывается недостаточно для того, чтобы скрыть всю сложность COM. Даже при использовании относительно простого совместимого с COM языка (например, VB6), вы все равно вынуждены бороться с "хрупкими" параметрами регистрации и многочисленными проблемами, связанными с инсталляцией приложений (в совокупности называемыми "кошмаром DLL").
Ко всем указанным выше сложностям еще добавляется такая мелочь, как Интернет. За последние несколько лет Microsoft добавила в свое семейство операционных систем и других продуктов множество связанных с Интернет возможностей. К сожалению, создание Web-приложений в рамках совместимой с COM архитектуры Windows DNA (Distributed interNet Applications Architecture – архитектура распределенных сетевых приложений) также оказывается очень непростым делом.
Некоторая доля этой сложности вытекает из того простого факта, что Windows DNA требует использования множества технологий и языков (ASP, HTML, XML, JavaScript, VBScript, а также COM(+) и API доступа к данным, например ADO).
Одной из проблем является то, что с синтаксической точки зрения многие из этих технологий совершенно не связаны одна с другой. Например, в JavaScript используется синтаксис, во многом подобный C, a VBScript является подмножеством VB6. COM-серверы, созданные для работы в среде выполнения COM+, по виду сильно отличаются от ASP-страниц, которые их вызывают. Результат – чрезвычайно запутанная смесь технологий.
К тому же, и это, возможно, самое важное, каждый язык и каждая технология имеют свои собственные системы типов (которые могут быть совершенно не похожими одна на другую). Например, нельзя сказать, что "int" в JavaScript и "Integer" в VB6 означают в точности одно и то же.
Слишком много для короткого урока истории. Основным выводом является то, что жизнь программиста Windows была трудна. Каркас .NET Framework является достаточно радикальной "силовой" попыткой сделать нашу жизнь легче. Решение, предложенное .NET, предполагает "изменить все" (извините, вы не можете обвинять посыльного за такое известие). Вы поймете из дальнейшего материала книги, что .NET Framework – это совершенно новая модель для создания систем как в семействе операционных систем Windows, так и множестве операционных систем, отличных от систем Microsoft, таких как Mac OS X и различные варианты Unix/ Linux. Чтобы это продемонстрировать, вот вам краткий список некоторых базовых возможностей, обеспечиваемых .NET.
• Полноценная возможность взаимодействия с существующим программным кодом. Это (конечно) хорошо. Существующие бинарные COM-объекты могут комбинироваться (т.е. взаимодействовать) с более новыми бинарными .NET-объектами и наоборот. Кроме того, сервисы PInvoke (Platform Invocation Services – сервисы вызова платформ) позволяют вызывать библиотеки на базе C (включая API операционной системы) из программного кода .NET.
• Полная и тотальная интеграция языков. В отличие от COM, платформа .NET поддерживает межъязыковое наследование, межъязыковую обработку исключений и межъязыковую отладку.
• Общий механизм выполнения программ для всех языков с поддержкой .NET. Одной из особенностей этого механизма является четкий набор типов, "понятных" каждому языку.
• Библиотека базовых классов. Эта библиотека позволяет избежать сложностей прямого обращения к API и предлагает согласованную объектную модель, используемую всеми языками с поддержкой .NET.
• Отсутствие детализации COM. В собственном бинарном .NET-объекте небудет места для IClassFactory, IUnknown, IDispatch, IDL-кода и "злобных" типов данных наподобие VARIANT (BSTR, SAFEARRAY и т.д.).
• Упрощенная модель инсталляции. Согласно спецификациям .NET, нет необходимости регистрировать соответствующую бинарную единицу в реестре системы. К тому же .NET вполне допускает существование множества версий одного *.dll на одной машине.
На основе информации этого списка вы, вероятно, уже сами пришли к заключению, что платформа .NET не имеет ничего общего с COM (за исключением того, что оба эти каркаса разработки приложений исходят из Microsoft). Фактически единственным способом взаимодействия типов .NET и COM оказывается использование возможностей слоя взаимодействия.
