Главная страница Visual 2000 · Общий список статей
Публикации в журнале BYTE/Россия · Публикации на тему MS .NET

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

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

© Андрей Колесов, 2001
Авторский вариант. Статья была опубликована c незначительной литературной правкой в журнале BYTE/Россия N 1/2001.
Примечание автора:
  1. Эта статья — моя первая публикация с попыткой технологического обзора архитектуры MS .NET и Visua Studio .NET. Она отражает мое восприятие (сформированное на основе доступной тогда информации) данной технологии на тот момент. По мере изучения MS .NET мои представления уточнялись и даже изменялись. Поэтому я рекомендую познакомиться с моими более поздними публикациями (начиная с декабря 2001 года).
  2. Здесь отсутcтвуют рисунки (они у меня потерялись), которые приведены в журнале. Статья от этого ничего не потеряла, так как более адекватные иллюстации имеются в последующих статьях на эту тему.


Смотрите также отдельную врезку к этой статье "Реализация объектно-ориентированной модели языка в Visual Basic .NET".

Эта статья открывает в журнале...

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

В начало статьи

Впереди непростой путь от VS 6.0 к VS.NET

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

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

С объявлением летом 2000 года новой стратегии развития технологий Microsoft сразу же появились сравнения с долгими периодом перемещения от 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. В момент появления первых слухов о будущей VS 7.0 говорилось, что новая версия ожидается в начале 2001 года. В ноябре вышла первая бета-версия VS.NET и неофициально представители Microsoft говорят о появлении финального релиза не ранее конца 2001 года. Возможно, ее выпуск будет увязан с выходом Whistler. А раз так, то весьма вероятен перенос сроков и далее, на 2002 год.

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

В начало статьи

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

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

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

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

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

В начало статьи

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

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

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

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

В начало статьи

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

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

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

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

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

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

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

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

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

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

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

В начало статьи

"DLL-ад" прекратится?

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

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

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

В начало статьи

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

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

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

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

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

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

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

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

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

ASP+ и Web Forms

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

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

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

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

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

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

В начало статьи

Web Services

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

Упрощенно говоря, в данном случае приложение обращается за выполнением некоторой функции не к DLL или ActiveX DLL, а к компоненту на удаленном компьютере с помощью Интернет-протокола. Для создания нового типа компонентов выполняется в VB.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. При построении проекта с данной функцией VB автоматически сформирует XML-описание этой функции и опубликует его на Web:

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

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

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

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

В начало статьи

Новшества среды разработки

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

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

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

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


MyString$ = Mid$(,1)

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

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

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

В начало статьи

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

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

В начало статьи