В ожидании Visual Studio.NET

Андрей Колесов

Такое выделение инструментов из состава технологий Microsoft, впрочем, достаточно условно, хотя бы потому что большинство серверных систем корпорации также представляют собой средства создания ИС. Но особое внимание к Visual Studio объясняется тем, что мимо реализованных в нем базовых технологий вряд ли сможет пройти тот, кто создает приложения для Windows.

Непростой путь от Visual Studio 6.0 к Visual Studio.NET

Довольно легко можно спрогнозировать, что 2001 год для разработчиков Microsoft (так почему-то принято называть людей, которые используют средства разработки компании Microsoft) будет периодом внимательного изучения архитектуры .NET и ее важнейшей составляющей, которая получила название .NET Framework. Мы будем внимательно следить за этой темой на страницах журнала, не забывая при этом и существующие сегодня технологии в виде Visual Studio 6.0. Почему?

Как мне кажется, выпуск Visual Studio.NET не будет похож на обычную смену версий инструментария, когда новый вариант почти автоматически сменяет старый. Вполне вероятно, что нас ожидает достаточно сложный процесс перехода от архитектуры традиционной Windows к .NET — с параллельным существованием двух линий средств разработки (версии 6 и .NET) в течение некоторого времени. Тем более, что сейчас мы наблюдаем активный процесс поэтапной адаптации Visual Studio 6.0 к технологиям .NET (например, использование ASP+, DAO+).

Когда летом 2000 г. была объявлена новая стратегия развития технологий Microsoft, сразу же появились сравнения с долгим периодом перехода от MS-DOS к Windows. Но такое сопоставление не очень точно, так сейчас процесс будет более эволюционным. В данном случае, возможно, лучше вспомнить переход в середине 90-х гг. от 16-разрядной архитектуры Windows к 32-разрядной, сопровождавшийся повсеместным внедрением стандартов ActiveX и COM.

Будущее Visual Studio.NET в туманной дымке

Первая информация о будущей версии Visual Basic 7.0 (о других инструментах тогда речь не шла) появилась в начале 2000 г. и сразу привлекла внимание специалистов прозрачными намеками на множество ожидающих нас сюрпризов. Речь тогда шла о реализации в полном объеме объектно-ориентированного языка и некоем радикальном изменении используемых Web-технологий.

В июне Microsoft анонсировала свою стратегию перехода к архитектуре .NET. Первое впечатление было таким: речь идет либо о довольно отдаленном будущем, либо о маркетинговом ходе целью обновить названия привычных технологий. Второй вариант стал казаться особенно близким к истине, когда наименованиям будущих версий продуктов Microsoft стали спешно присваивать суффикс .NET. Однако появившаяся осенью информация об архитектуре .NET Framefork показала, что речь действительно идет о весьма серьезных и не очень отдаленных переменах. Появление первой публичной бета-версии Visual Studio.NET (и почти одновременный выход бета-версии будущей ОС под кодовым названием Whistler) еще более четко подтвердили серьезность намерений Microsoft внести решительные изменения в свои технологии разработки.

Здесь нужно сделать два важных замечания.

1. Хотя Microsoft и утверждает, что объявление о начале реализации инициативы .NET случайно совпало по времени с решением судьи Джонсона, угрожающим будущему корпорации, однако некоторая связь тут все же улавливается. Вполне возможно, что форсирование весьма радикальных изменений в архитектуре ОС и в технологии разработки объясняется желанием, с одной стороны, еще сильнее связать между собой ядро ОС и приложения (а ведь министерство юстиции США стремится именно к разделению бизнеса операционных систем и прикладных программ), а с другой — продемонстрировать приверженность Microsoft открытым стандартам XML.

2. В момент появления первых слухов о Visual Studio 7.0 говорилось, что новая версия ожидается в начале 2001 г. В ноябре вышла первая бета-версия Visual Studio.NET, и неофициально представители Microsoft говорят о появлении финального релиза не ранее конца 2001 г. Возможно, ее выпуск будет увязан с выходом Whistler. А раз так, то весьма вероятен перенос сроков и далее, на 2002 г.

В то же время я бы предложил относиться к первой бета-версии Visual Studio.NET как к весьма приближенному прототипу того, что мы получим в окончательном варианте: в ней появится что-то новое, а что-то из уже объявленного может не прижиться. Ведь при бета-тестировании подобных продуктов происходит не только отладка и устранение ошибок, но и изучение рынка на предмет его готовности к восприятию предлагаемых инноваций.

Первый взгляд на Visual Studio.NET

Бета-версия только появилась, и ее детальное изучение еще впереди (возможно, для практической работы серьезное исследование вообще нужно начинать со второй бета-версии). Но то, что разработчиков ожидает много новшеств и сюрпризов, можно констатировать уже сегодня. Это следует хотя бы из того, что для работы Visual Studio.NET Beta 1 требуется как минимум 128 Мбайт оперативной памяти и процессор Pentium II 450 МГц (рекомендуемая конфигурация — 256 Мбайт и Pentium III 733 МГц).

Если первые два выпуска объединенного пакета средств разработки — Visual Studio 97 (март 1997 г.) и Visual Studio 6.0 (сентябрь 1998 г.) — представляли собой набор автономных инструментов, то нынешний являет собой пример реальной интеграции разных систем программирования.

Как и было объявлено, в Visual Studio.NET реализована поддержка четырех языков программирования — Visual Basic, C++, C# и JStript, объединенных единой технологией .NET Framework и средой разработки. Из списка автономных продуктов предыдущих выпусков исчез InterDev — он включен в состав интегрированной среды разработки (на его базе реализуются, например, технологии ASP+ и Web Forms) и теперь может использоваться при работе любого инструмента Visual Studio.NET. А вот Visual J++ пропал и, похоже, навсегда.

В состав Visual Studio.NET входит Visual FoxPro 7.0 в виде автономного продукта, не связанного с .NET Framework (здесь показательно цифровое обозначение его версии). Появление обновленного варианта СУБД, сохраняющей довольно высокую популярность, весьма примечательно на фоне длящихся уже почти пять лет разговоров по поводу ее будущего. (В 1996 г. Microsoft, увидев негативную реакцию пользователей на слухи о возможном прекращении развития FoxPro, решила выпустить версию 5.0, хотя и без твердых гарантий относительно 6.0. И вот теперь появилась версия 7.0.) Тем не менее дистанцирование Visual FoxPro 7.0 от остальных инструментов .NET, возможно, должно показать, что время жизни этого инструмента все же заканчивается.

Архитектура .NET Framework

Стратегия развития средств разработки Microsoft определяется тем, как реализована архитектура построения приложений .Net Framework (рис. 1). Под "системными" здесь понимаются сервисы операционных систем семейства Windows, над которыми располагаются три базовых уровня компонентов.NET Framework: среда исполнения Common Language Runtime (CLR), сервисы Framework (или иначе библиотеки стандартных классов) и поддержка диалогового интерфейса с удаленными (ASP+ в сочетании с Web-формами и Web-сервисами) и локальными (Win-формы) пользователями.

Рис. 1.

Сами же прикладные программные компоненты пишутся на любых языках, которые поддерживают данную архитектуру, включая, разумеется, Visual Basic, C++, C# и JScript, входящие в состав Visual Studio.NET. Microsoft позиционирует данную архитектуру как открытый стандарт, доступный другим разработчикам. Одновременно с выпуском первой бета-версии Visual Basic.NET корпорация совместно со своими партнерами Intel и Hewlett-Packard передала спецификации нового языка C# и среды Common Language Infrastructure в международную организацию по Интернет-стандартам ECMA. По данным Microsoft, в настоящее время эта архитектура используется (или ее планируется использовать) примерно в 20 языках независимых разработчиков, в том числе в таких, как COBOL, Perl, Java, SmallTalk, Oberon и некоторые другие.

Хотелось бы сразу отметить, что с точки зрения идей организации программных систем архитектуру .NET Framework трудно назвать революционной — ее аналоги можно найти в технологиях еще 20–30-летней давности. Скорее интересен вопрос ее физической реализации на очередном витке исторического развития систем программирования. Но как раз здесь многое пока остается довольно туманным.

CLR и библиотеки классов

Одна из ключевых идей .NET Framework — реализация прикладных программных компонентов в виде не машинных кодов (native, "родных" для компьютера конкретной архитектуры), а так называемого байт-кода, написанного на языке Microsoft Intermediate Language (MSIL), который затем будет "исполняться" средой CLR (транслятором с помощью библиотек поддержки).

Вообще говоря, идея преобразования исходного кода в компактный промежуточный внутренний код была реализована еще в 60-х гг. для ускорения выполнения Basic-программ в режиме интерпретации. Спустя примерно десять лет было предложено использовать промежуточный P-код (P — Portable или Pascal) для создания "Виртуального Паскаля" с целью минимизации затрат при разработке компиляторов Pascal для разных платформ. В середине 90-х гг. именно этот подход был реализован в технологии Java для обеспечения платформенной независимости.

В отличие от Java байт-код в CLR будет выполняться не в режиме интерпретации, а путем предварительной компиляции отдельных фрагментов программы или приложения целиком. Но как это будет реализовано на самом деле — пока не очень понятно. Напомним, что Microsoft разрешила компилировать программы на Visual Basic только с появлением его пятой версии, хотя ни о какой платформенной независимости для них речь тогда не шла ("настоящие" компиляторы были в Microsoft Basic еще во времена MS-DOS).

Тут в качестве примера можно упомянуть еще способ выполнения программного кода, реализованный в системе "1С:Предприятие". Программные модули хранятся в конфигурации (именно так в терминах "1С" называется прикладная программа) в виде исходного текста, и компиляция каждого из них выполняется только в момент первого обращения, после чего его машинный код сохраняется в оперативной памяти. Таким образом, компиляция программ происходит каждый раз при запуске приложения, но благодаря распределенной схеме трансляции эта операция практически незаметна для пользователя.

В данном случае технология CLR — это шаг вперед в плане языковой независимости. (Ранее речь шла об адаптации одного языка для разных платформ, а сейчас — об адаптации разных языков для одной платформы.) Логическое ее дополнение — реализация унифицированного набора функций в виде библиотек стандартных классов.

Все это выглядит довольно привлекательно, но стоит сделать два замечания:

1. Унификацию компонентов языков программирования Microsoft начала еще в конце 80-х гг., используя единые внутренние конструкции и библиотеки подпрограмм для тогдашних QuickBasic и QuickC. Компилятор Visual Basic 5 вообще был реализован с использованием промежуточного кода на языке C.

2. Следует помнить, что любая унификация имеет и негативные последствия в виде потери специфических особенностей того или иного языка программирования, что, кажется, может произойти с Visual Basic.NET. На самом деле разнообразие языков определяется тем, что они нацелены на решение различных классов задач, иначе мы бы уже давно имели один язык программирования на все случаи жизни.

Получается, что фактически идеология .NET Framework заключается в преобразовании программных компонентов, объединенных ранее в виде EXE-модуля на этапе его компоновки, в вид автономных объектов, а также в более широком использовании технологии "позднего связывания" вместо "раннего", со всеми вытекающими из этого плюсами и минусами. Во всяком случае, резкий рост аппаратных требований — это прямое следствие реализации "объектной модели".

В качестве довода в пользу CLR называется возможность смешанного использования программных компонентов, написанных на разных языках. Однако тут можно вспомнить, что реализованная еще 40 лет назад идея разделения процедур компиляции (трансляция исходных модулей в объектные) и компоновки (объединение объектных модулей в один загрузочный) подразумевала, в частности, возможность использования для создания одной программы разных языков программирования (так называемая технология смешанного программирования). Сейчас эту технологию почему-то подзабыли, но еще во времена MS-DOS ее применение было вполне обыденным делом.

«DLL Hell» прекратится?

Неприятным следствием перехода от монолитного исполняемого модуля программы к распределенной компонентной модели становится снижение надежности. Все это хорошо известно на примере постоянных проблем, связанных с использованием общих DLL и OCX, которые неконтролируемым образом меняют версии, удаляются и пр. В результате дистрибуция приложений, их установка или удаление уже давно превратилась в испытание нервов разработчиков и пользователей, которое получило название «DLL Hell» («DLL-ад»).

В новой архитектуре Microsoft делает обратный шаг в сторону связывания воедино всех необходимых компонентов приложения. Тут предусмотрены два варианта "сборки" (assembly) пакетов — частные (для одного приложения) и общие (для нескольких). Контроль за версиями будет выполняться с помощью подписи автора компонента, но главная гарантия повышения надежности — возврат к старому проверенному способу инсталляции приложений в виде простого копирования всех его файлов в отдельный каталог. При этом информация о конфигурации будет храниться в XML-файле, который можно редактировать любым текстовым редактором.

Все новое — это хорошо забытое старое. Поскольку мы уже успели забыть о простых механизмах описания конфигураций пакетов в виде INI-файлов, самое время высказать пожелание, чтобы Microsoft прекратила еще и «Registry Nightmare»…

Обновление языков

Модификация Visual C++ связана его с адаптацией к архитектуре .NET и использованием обновленной технологии Active Template Library (ATL) Server, которая должна упростить разработку высокопроизводительных масштабируемых Web-приложений с применением Internet Information Server. По некоторым сведениям, Microsoft намерена сделать Visual C++ единственным средством создания компонентов на "родном" коде. Так что Visual Basic, возможно, придется распрощаться с этой возможностью, дарованной ему лишь в 1997 г.

Исчезновение из Visual Studio.NET инструмента Visual J++ и появление C# свидетельствует о том, что дороги Microsoft и Java расходятся. В силу разных причин (во многом из-за сильной привязки к Windows) популярность Visual J++ осталась на весьма низком уровне. К тому же в начале 2001 г. у Microsoft заканчивается лицензия на Java, и она вряд ли будет продлена.

По версии Microsoft, появление C# (произносится как «си-шарп», а пишется как «си-диез» — на полтона выше ноты «си») объясняется необходимостью интеграции языка C с новыми Интернет-технологиями, что невозможно без нарушения ANSI-стандартов. Так или иначе, но очевидно, что, с одной стороны, C# создается в качестве прямого конкурента Java и нас ожидает новый виток увлекательной конкуренции между Microsoft и Sun. С другой стороны, С# дает возможность использовать средства быстрой разработки традиционным C-программистам, которые не хотят иметь дело с Visual Basic.

В Visual Basic.NET произошли огромные изменения, и оценить возможные их последствия пока довольно сложно. Еще в начале 2000 г. довольно единодушные высказывания экспертов по поводу ожидаемых инноваций в Visual Basic определяли их как "превосходящие все ожидания". В этой связи редактор «Visual Basic Programmers Journal» Патрик Мидер сопроводил информацию о Visual Basic 7.0 таким комментарием: «Возможно, новшества в Visual Basic 7.0 вызовут огромное негодование как у критиков, так и у давнишних пользователей этой системы».

Причиной недовольства первой группы станет то, что у них отнимут многие аргументы против Visual Basic. А гнев второй можно объяснить простым вопросом: "Почему для того чтобы, наконец, получить эти функции, мы были вынуждены ждать шести предыдущих версий в течение почти десяти лет?". Сейчас, когда новшества Visual Basic.NET приобрели более конкретный характер, многие Visual Basic-программисты оценивают их далеко не однозначно ("не до такой же степени!").

Visual Basic наконец-то стал полноценным объектно-ориентированным языком, и Visual Basic-программисты могут избавиться от чувства ущербности по поводу его "несовременности" (см. врезку "Реализация объектно-ориентированной модели языка в Visual Basic.NET"). Безусловно, Visual Basic.NET серьезно прибавил в мощности средств, но работать с ним будет сложнее. Ведь объектно-ориентированные методы программирования предъявляют более серьезные требования к квалификации разработчика, на которого перекладываются многие проблемы обеспечения работоспособности программы.

В этой ситуации вопрос о том, в какой степени сообщество Visual Basic-разработчиков готово к такому довольно радикальному расширению возможностей Visual Basic, представляется не столь простым. Тем более, что хотя Visual Basic широко используется профессиональными разработчиками, он до сих пор позиционировался как удобная технология для начинающих программистов. Возникает также вопрос: как эти новшества будут отражены в Visual Basic for Applications, большинство пользователей которого имеют минимальную программистскую подготовку?

И совсем неожиданной новостью стало то, что реализованные в Visual Basic.NET концепции, скорее всего, приведут к нарушению традиционной поддержки совместимости "снизу-вверх" — перенос приложений из Visual Basic 6.0 в Visual Basic.NET будет очень непростым. (В следующем номере журнала мы расскажем об этом подробнее).

Технологии ASP+ и Web Forms

Речь здесь идет не просто о конструировании Web-форм, а о новой технологии создания Web-приложений, которую будут поддерживать все инструменты, входящие в состав Visual Studio.NET. Как известно, в настоящее время Visual Basic 6.0 поддерживает два типа Web-приложений — WebClass (серверные) и DHTML (клиентские), а InterDev обеспечивает разработку Active Server Pages (ASP). Такое разнообразие создает для пользователей определенные проблемы выбора, так как функциональность разных методов различается.

Как полагает Microsoft, новая технология ASP+ должна стать преемницей ASP и WebClass, объединив достоинства обеих. Тем не менее создается впечатление, что речь идет скорее о развитии технологии WebClass, реализованной в Visual Basic 6.0. Страница Web Forms состоит из двух частей: шаблона в виде HTML-файла и файла с программным кодом. Такое разделение, в частности, повышает скорость выполнения программы, так как используется режим выполнения машинного кода (DLL), а не интерпретации скрипта. Кроме того, для написания кода можно применять любой язык программирования, и создаваемые компоненты можно использовать повторно.

В ASP+ обещано повышение надежности за счет использования специальных виртуальных доменов и механизма сохранения состояния процесса для перезапуска из-за возможных сбоев. Создавать HTML-шаблоны можно с помощью встроенного редактора или внешнего, специализированного.

Подразумевается, что программисты смогут формировать Web-интерфейсы почти точно так же, как они создают сейчас формы Windows в Visual Basic (рис.2). Используя палитру инструментальных средств, специально сгенерированных, чтобы поддержать любую указанную версию HTML, можно будет с помощью метода "перетащи и оставь" создавать пользовательский интерфейс на базе Web и писать сервер-ориентированный код для каждого объекта так же, как это делается для форм на базе Windows. Код для Web-форм постоянно находится на сервере, а HTML генерируется "на лету". Элементы управления Web-форм преобразуются в HTML-объекты по мере выполнения кода на сервере.

Рис. 2.

Все это звучит очень заманчиво, но как будет на самом деле, пока сказать трудно. Тут можно вспомнить, что обещания сделать разработку Web-приложений простой и удобной давались и перед выходом Visual Basic 6.0. Однако на практике оказалось, что технология разработки и особенно отладки Интернет-приложений (WebClass и DHTML) в Visual Basic 6.0 весьма запутанна и неудобна, а встроенный конструктор Web-форм — откровенно слабый. Посмотрим, что нас ожидает на этот раз.

В плане подготовки к использованию технологии ASP+ и Web Forms рекомендуется применять многоуровневую архитектуру приложений. В этом случае переход к Web-приложениям сведется к достаточно простой замене интерфейса.

Web Services

Web Services — это некая принципиально новая платформно-независимая технология, связанная с использованием стандарта XML и протокола SOAP (Simple Object Access Protocol — протокол доступа к простым объектам), которая будет широко интегрирована в средства разработки. Тут пока еще многое неясно, но ключевая идея состоит в создании компонентов уровня бизнес-логики, которые взаимодействуют с внешними объектами с помощью стандартных Web-протоколов (рис.3). При этом Microsoft обещает обеспечить совместимость с Unix и Linux.

Рис. 3.

Упрощенно говоря, в данном случае приложение обращается за выполнением некоторой функции не к DLL или ActiveX DLL, а к компоненту на удаленном компьютере с помощью Интернет-протокола. Для создания нового типа компонентов в Visual Basic.NET существует новый тип проекта, называемый Web Service. Выглядит это примерно следующим образом:

1. Разработчик создает проект типа Web Service с названием RatingService, добавляет в него модуль класса с именем ClassComponent и пишет функцию для решения некоторой задачи:

Public Function GetRate (ByVal ticker As String) As String
  'Решаем — покупать или продавать акции
  If ticker = "ACME" Then
    GetRate = "Покупать!"
  Else
    GetRate = "Продавать!"
  End If
End Function

2. При построении проекта с данной функцией Visual Basic автоматически сформирует XML-описание этой функции и опубликует его на Web:

<?xml version='1.0' ?> <methods href='http://url/RatingService'>
  <method name='GetRate' href = 'GetRate'>
    <request>
      <param dt='string'>ticker</param>
    </request>
  </method>
</methods>

3. Теперь можно обратиться к этой функции с помощью обычного браузера (с включенной в него поддержкой XML). Наберите URL http://url/RatingService/component.methods/GetRate?ticker=AMCE и вы получите в окне браузера результат:

<?xml version='1.0' ?> <response>Покупать</response>

Созданные средства Web Services можно также подключать к Visual Basic-проекту. Причем эти функции могут быть созданы, например, с помощью Unix-инструментов и работать в среде Web-сервера Apache.

Среда разработки

Как уже было сказано, языки программирования, включенные в состав Visual Studio.NET (кроме Visual FoxPro), используют единую интегрированную среду разработки. Тут появилось довольно много новшеств, и многие из них действительно окажутся полезными.

Например, теперь при запуске программы будет появляться специальное окно Start (рис. 4), в котором разработчик сможет делать разнообразные установки для организации среды (расширенный вариант бывшего окна Options). Новое окно Server Explorer обеспечит программисту доступ к разнообразным серверным ресурсам. Еще одно полезное средство — специальное окно Task List, с помощью которого разработчик сможет "протоколировать" ход выполнения проекта, фиксировать выявленные ошибки и способы их устранения, записывать идеи для будущей реализации.

Рис. 4.

Серьезной модификации подверглась панель инструментов Toolbox, которая теперь включает встроенные элементы управления для Web- и Windows-форм, элементы управления ActiveX, элементы HTML, объекты, а также компоненты буфера обмена. Интеллектуальная подсказка IntelliSence будет появляться не только для компилируемых языков, но и для HTML и XML (рис. 5).

Рис. 5.

Microsoft наконец-то решила усилить синтаксический контроль при вводе программного кода. Например, при вводе строки на Visual Basic.NET

<p>MyString$ = Mid$(,1)

сразу же будет выдаваться сообщение о неверном синтаксисе функции Mid$. Но лично меня это новшество немного огорчает: такой контроль был реализован еще почти 15 лет назад в QuickBasic, и непонятно, почему до появления его в Visual Basic должно было смениться целых семь версий. Нужно также отметить, что механизм навигации по компонентам проекта (на уровне процедур) по-прежнему оставляет желать много лучшего.

Появился набор новых или модернизированных конструктов — Web Form, Windows Form, Component, XML. Обновлен и расширен состав средств Visual Database Tools.

И еще одна любопытная новость — для автоматизации работы в среде и ее оптимальной настройки в Visual Studio появился механизм создания макрокоманд на Visual Basic for Applications, который хорошо знаком пользователям Microsoft Office.

"Что день грядущий мне готовит…

Пока понятно лишь одно — появление архитектуры .NET Framework знаменует собой весьма серьезные изменения в технологии разработки, которые могут оказаться сопоставимы с переходом от MS-DOS к Windows. Перенос существующих сегодня приложений из Visual Studio 6.0 в Visual Studio.NET будет очень непростым и неминуемо вызовет увеличение спроса на программистов. Самих разработчиков ожидает новый период активного освоения новых технологий. Руководители ИТ-подразделений уже сегодня должны планировать увеличение расходов в связи с расширением персонала и обновлением оборудования. На смену "Проблеме 2000" идет "переход на .NET".

Protected cName As String
Protected Function ChangeName(NewName)
  Me.cName = NewName
End Function

Sub CreateMyThread()
  Dim b As BackGroundWork
  Dim t As Thread
  Set b = New BackGroundWork
  Set t = New Thread(New ThreadStart (AddressOf b.Doit))
  t.Start
End Sub

Class BackGroundWork
  Sub Doit()
  ...
  End Sub
End Class

Class1
  Function GetCustomer()
  ...
  End Function

Class2
  Inherits Class1
  Function GetOrders()
  ...
  End Function

Overloads Sub Display (theString As String)
...
Overloads Sub Display (theInteger As Integer)

Class Employee
  Function PayEmployee
    'почасовая оплата
    PayEmployee = Hours * HourlyRate
  End Function

Class CommissionedEmployee
  Inherits Employee
  Function PayEmployee
    'сдельная оплата
    PayEmployee = BasePay + Commissions
  End Function

Try      'начало некоторой операции
  Open "TestFile" For Output As #1
  Write #1, SomeInformation$
Catch    'в случае ошибки выполняется этот код:
  Kill "TestFile"
Finally  'при отсутствии ошибки выполняется этот код:
  Close #1
End Try