Самоучитель по VB.NET
Глава 3.
Стратегии перехода
Вероятно, вы уже встречали информацию о .NET в журнальных статьях или на сайте Microsoft. Может быть, вы принимали участие в семинарах «Дней программиста» или других конференциях. Но даже если вы впервые столкнулись с .NET в этой книге, несомненно, у вас уже возникли важные вопросы.
Не рассчитывайте, что я отвечу на эти вопросы — они слишком сильно зависят от вашей конкретной ситуации. Вместо этого мы поговорим о тех факторах, которые необходимо учитывать при поиске ответов. По мере знакомства с технологическими аспектами .NET вы сможете воспользоваться своими новыми знаниями и найти ответы самостоятельно.
Когда я приступил к работе над этой главой, официальная бета-версия Visual Studio .NET еще не распространялась. Microsoft уже успела опубликовать немало маркетинговых сведений о .NET, выпустила несколько статей с описанием технологии и архитектуры, а также распространила технологический обзор на своей Конференции профессиональных разработчиков. Но даже сейчас1 еще неизвестно, когда выйдет окончательная версия Visual Studio .NET. Вероятно, это произойдет во второй половине 2001 года. Следовательно, вся эта новая технология вполне реальна, но говорить о ее массовом применении пока рановато.
1 На стадии бета-2.
У ранней рекламной кампании Microsoft есть и оборотная сторона: программисты могут решить, будто VB6 уже устарел, поэтому нужно побыстрее изучать VB .NET и разбираться, как адаптировать существующие приложения для него. Конечно, это полная ерунда.
Даже после выхода окончательной версии программистам понадобится немало времени на освоение новой технологии и ее практическое внедрение. Масштаб изменений настолько велик, что на переход к VB .NET потребуются годы, а не месяцы — а для некоторых приложений это вообще бессмысленно.
Что же это означает лично для вас?
1. Не выбрасывайте свою версию Visual Basic. Вероятно, она вам еще понадобится в течение некоторого времени.
2. Не паникуйте! У вас будет время на то, чтобы освоить эту новую технологию и привыкнуть к ней.
3. Читайте книги, учитесь и экспериментируйте перед тем, как приступать к проектированию приложений и непосредственному программированию. Это увеличит вероятность того, что ваши приложения окажутся правильно спроектированными и будут в полной мере использовать новые возможности .NET.
Один из самых важных вопросов, на который вам предстоит ответить, — нужно ли адаптировать код существующих приложений для VB .NET. В предыдущих версиях Visual Basic принять решение было несложно. Переходы от VB1 к VB4 (16-разрядная версия) у большинства программистов происходили легко; лишь немногим из них приходилось откладывать переход на новую версию из-за проблем совместимости. Переход на 32-разрядный Visual Basic вызвал больше затруднений, однако основные задержки были связаны с ожиданием выхода компонентов ActiveX в новых OCX-версиях (вместо 16-разрядных VBX-Bepсий). Переходы от 32-разрядного VB4 к VB6 также проходили относительно гладко. Хотя Microsoft приложила огромные усилия к тому, чтобы обеспечить обратную совместимость, решить эту задачу полностью так и не удалось, а в процессе обновления нередко появлялись хитроумные ошибки. Из-за этого даже в наши дни некоторые программисты продолжают использовать VB5.
А теперь представьте, как будет проходить адаптация кода на язык, в котором совместимость была нарушена намеренно?
Еще раз подчеркну, что я не критикую решение Microsoft о нарушении совместимости — на это у них были веские причины. Но это означает, что адаптация существующего кода в VB .NET потребует основательных затрат.
Во сколько обойдется адаптация готовых программ? Все зависит от качества вашего кода и от того, насколько хорош будет Migration Wizard.
Даже если Migration Wizard сможет правильно преобразовать 95 % программы из 10 000 строк, по крайней мере 500 строк придется просматривать, анализировать и обновлять вручную, не говоря уже о возможности появления нетривиальных ошибок, обусловленных изменением архитектуры или самим процессом адаптации. По крайней мере, все адаптированные приложения и компоненты придется тщательно тестировать.
Что это значит для вас как для разработчика? То, что вы должны сопоставить затраты на адаптацию с преимуществами, которые она дает. Неизбежно выяснится, что в некоторых ситуациях адаптация существующего кода в VB .NET экономически невыгодна, поэтому Microsoft следовало бы в течение некоторого времени продавать и поддерживать Visual Basic 61.
Причины перехода на .NET могут сильно различаться в зависимости от того, какие приложения и компоненты вы разрабатываете. Ниже перечислены некоторые ключевые факторы, влияющие на внедрение новой технологии.
Все эти факторы позволяют высказать обоснованные предположения относительно того, в каких областях и насколько быстро будет задействована технология VB .NET.
1Я не слышал от Microsoft никаких официальных заявлений относительно будущего VB6, однако мое общение с сотрудниками Microsoft показывает, что они понимают суть проблемы, и некоторые высказываются за продолжение поддержки VB6 даже после выхода VB .NET.
Здесь и думать не о чем. Если вы работаете над новым серверным приложением, будь то web-приложение ASP.NET, код принятия решений на стороне сервера или бизнес-логика среднего уровня (middle tier), переход на VB .NET вскоре после выхода окончательной версии (или даже на стадии разработки поздней бета-версии) выглядит вполне логично. Все затраты сводятся к времени и расходам на обучение программистов. Правда, это может обойтись недешево, однако затраты быстро оправдаются дополнительными преимуществами — такими, как повышение надежности и доступ к новым возможностям .NET. Поскольку приложение работает только на серверах, затратами на установку и внедрение исполнительной системы можно пренебречь.
Аргументы примерно те же, что и в предыдущем случае, однако появляются новые затраты на адаптацию кода. Как упоминалось выше, эти затраты могут быть весьма существенными. К счастью, архитектура .NET спроектирована таким образом, что она хорошо работает с существующей технологией СОМ и компонентами (хотя, как вы вскоре узнаете, сама технология .NET не основана на СОМ). Это означает, что вы сможете избирательно адаптировать некоторые компоненты своего приложения для .NET, чтобы воспользоваться новыми возможностями, улучшенным быстродействием или масштабируемостью, и продолжить применение существующих компонентов СОМ в тех аспектах вашего решения, которые не выиграют от адаптации, или же если она обойдется слишком дорого.
В этом случае я бы порекомендовал пораньше начать обучение персонала,' проанализировать различные компоненты системы и определить, какие из них стоит адаптировать для новой технологии. Начинайте с небольших, простых компонентов, чтобы накопить практический опыт. Еще лучше начинать с компонентов, которые добавляются для реализации новых возможностей в вашем приложении.
Сейчас еще рано что-либо уверенно утверждать, но я рекомендую сосредоточить внимание на компонентах, не обладающих пользовательским интерфейсом. Конечно, ничто не мешает объединять СОМ с компонентами .NET с пользовательским интерфейсом, однако это повышает риск возникновения всевозможных проблем и нетривиальных проявлений несовместимости в процессе адаптации. Таким образом, основное внимание следует уделять серверным приложениям, web-серверам и среднему уровню. Еще раз подчеркну, что мои опасения относительно совмещения СОМ с компонентами .NET, обладающими пользовательским интерфейсом, относятся только к адаптации кода, когда приходится учитывать весьма тонкие изменения в поведении программы. Использование существующих компонентов СОМ в новых проектах .NET (и наоборот) проблем не вызывает. Microsoft приложила немало усилий к тому, чтобы компоненты СОМ и .NET хорошо работали друг с другом.
Главным фактором при принятии решения об использовании VB .NET для создания компонентов клиентской стороны (будь то автономное приложение или браузерный компонент) должна быть ваша уверенность в том, что клиенты уже установили исполнительную среду .NET, собираются установить ее или уже перешли на версию Windows, в которую она входит. Окончательный размер дистрибутива исполнительной части мне пока неизвестен, но скорее всего он будет настолько большим, что минимальным требованием для пересылки файлов клиенту будет наличие Zip-накопителя, дисковода CD-ROM или модема DSL. Передача данных на гибких дисках и по обычному модему практически исключается.
Если на компьютере отсутствует исполнительная среда .NET, приложения и компоненты VB .NET просто не будут работать.
Однако наличие исполнительной среды не только открывает доступ к новым возможностям, но и позволяет организовать безопасную установку вашего приложения и его компонентов. Вам не придется беспокоиться о проблемах «кошмара DLL» (DLL Hell), так часто встречающихся при современной технологии1. Кроме того, вы сможете создавать защищенные, проверяемые компоненты и приложения — это особенно важно, поскольку распространение компьютерных вирусов заставляет конечного пользователя уделять все большее внимание безопасности системы.
После того как Common Language Runtime войдет в поставку операционной системы (а это практически неизбежно), VB .NET станет весьма привлекательной платформой для клиентских приложений и браузерных компонентов2. В частности, меня совсем не удивит, если .NET во многих ситуациях затормозит распространение клиентских приложений с расширенной функциональностью, поскольку в .NET надежная установка такого приложения ничуть не сложнее просмотра web-страницы.
Переход на .NET не должен проходить так драматично, как переход с 16- на 32-разрядные приложения, поскольку среда CLR должна работать на всех существующих 32-разрядных версиях Windows. Тем не менее, если учесть разнородный состав пользователей и систем, в которых они работают, становится ясно, что на первых порах VB .NET не будет хорошей платформой для большинства клиентских приложений.
Вероятно, внедрение .NET в клиентской области начнется с малых компаний, в которых можно проконтролировать состояние рабочего стола любого пользователя, при необходимости быстро свернуть исполнительную среду и разобраться с любыми возникшими проблемами. Разработчики коммерческих программ, скорее всего, будут избегать .NET до тех пор, пока накопившаяся информация не позволит обоснованно судить о применимости Common Language Runtime в широком спектре используемых систем.
1 Для тех, кто еще не знает этот термин, «кошмаром DLL» называется ситуация, при которой установка в системе обновленного компонента приводит к сбоям в работе других приложений. Ниже мы подробно рассмотрим эту проблему и процесс установки вообще.
2 Существует и такая эффектная возможность, как создание приложений, работающих на web-сервере или в локальной системе с практически одинаковым пользовательским интерфейсом.
Многие программисты Visual Basic страдали от легкого комплекса неполноценности (а программисты C++ называли Visual Basic «игрушечным языком» и развивали этот комплекс). Одни не выдержали и ушли изучать C++, другие переключились на Java1.
С приходом VB .NET неизбежно возникает вопрос, не следует ли программистам VB перейти на С# или C++.
Если вам решительно не хочется иметь дела с .NET, появляется дополнительный аргумент в пользу перехода на C++. Этот язык, как и прежде, обеспечивает превосходную поддержку создания Windows-приложений и компонентов, использующих библиотечные модули MFC или (с несколько большими усилиями) вообще обходящиеся без поддержки исполнительной системы. C++ остается общепринятым фаворитом для разработки специализированных приложений, таких как приложения ISAPI, использующие ATL Server. Впрочем, опытный программист VB, вероятно, все же предпочтет остаться с VB6.
Если вы решите, что платформа .NET в полной мере отражает стремление Microsoft создать платформу программирования нового поколения, что она не только просуществует в течение долгого времени, но и продолжит свое развитие и будет поддерживаться на уровне текущего Win32 API, я настоятельно рекомендую остановить выбор на СП или VB .NET вместо C++ с управляемыми расширениями (managed extensions).
С# разрабатывался вместе с Common Language Runtime как «идеальный» язык для среды .NET. Возможность создания высокоэффективного проверяемого кода была заложена в него изначально.
А как же VB .NET? Когда стало ясно, что адаптация Visual Basic к .NET потребует нарушения языковой совместимости с VB6, в Microsoft решили пойти до конца и сделать VB .NET полностью .NET-совместнмым языком. Также было решено «почистить» язык, видоизменить или исключить из него те самые факторы, которые обычно вызывали основную критику у программистов C++.
Другими словами, если вы собираетесь использовать .NET, между С# и VB .NET нет практически никаких различий ни по быстродействию, ни по набору поддерживаемых возможностей. С# дает большую свободу в использовании «ненадежного» кода — впрочем, этой низкоуровневой возможностью следует пользоваться лишь при крайней необходимости (более подробно эта тема рассматривается ниже). Но даже это не является достаточной причиной для того, чтобы отдать предпочтение С# перед VB .NET, поскольку в приложении можно легко смешивать разные языки2.
1 Далее я не собираюсь обсуждать Java. Мой опыт знакомства с этим языком не позволяет обоснованно оценить достоинства и недостатки Java как альтернативы VB6, VB .NET или С#.
2 Собственно, простота использования компонентов и программного кода других языков и была одной из главных причин для создания Common Language Runtime. Например, класс VB .NET не только «видит» объекты С#, но и может создавать от них производные объекты путем наследования. Насколько мне известно, в настоящее время разрабатываются восемнадцать .NET-совместимых языков!
В некоторых областях синтаксис VB .NET кажется более четким и наглядным, чем аналогичный синтаксис С#. Впрочем, это не означает, что из-за этого программисты должны переходить на VB .NET вместо С#.
В конечном счете вы можете придерживаться того синтаксиса, к которому привыкли1. Если вы программируете на Visual Basic, выбирайте VB .NET. Для программистов C++ и Java более привычным покажется С#.
1 Снова экономика. Зачем попусту тратить драгоценное время на изучение нового синтаксиса?
Некоторые читатели посмотрят на грандиозные изменения, связанные с переходом на .NET, и задумаются — а не лучше ли решать проблемы при помощи технологий и языков, не имеющих отношения к Microsoft? Я бы охотно помог советом в этой области, но, по правде говоря, я недостаточно хорошо ориентируюсь в этих альтернативах, чтобы их сравнивать. Более того, существующие платформы и языки изменяются так быстро, что любые сравнения просто не имеют смысла. Позвольте мне привести пару примеров.
Многие программисты VB поглядывают на Java и громкие обещания межплатформенной совместимости. К сожалению, большая часть совместимости так и остается на уровне обещаний, изрядно подпорченных корпоративной политикой, юридическими тонкостями и не лучшим быстродействием практических реализаций. Кстати говоря, ничто не мешает реализовать Java для .NET, но мне кажется, что при использовании .NET бессмысленно отдавать предпочтение Java перед С# (если только .NET-версия Java не будет реализована лучше других языков).
Microsoft особо подчеркивает как поддержку в .NET стандартов SOAP (Simple Object Access Protocol) и XML (Extensible Markup Language), так и то, что язык С# тоже должен быть оформлен в качестве стандарта. Впрочем, пока это всего лишь обещания, а переход от сегодняшнего состояния к окончательной стандартизации — дело политическое и неоднозначное.
Я не уверен, что для конкретного приложения можно подобрать «оптимальную» платформу, поскольку никто толком не знает, как будут развиваться события. Думаю, можно предположить, что в течение некоторого времени2 платформа .NET будет вполне жизнеспособна, но никто не запрещает вам исследовать другие возможности, даже если золотые крупинки стоящей информации придется выискивать в горах рекламного порожняка.
В этой книге предполагается, что вы, по какой бы причине это ни произошло, остановили свой выбор на технологии Microsoft. Свою задачу я вижу в том, чтобы по возможности облегчить ваш переход от сегодняшней технологии к .NET3.
2 Когда-то я работал в компании, которая одна из первых перешла на работу в графической среде. Мне пришлось выбирать между платформой GEM (Digital Research) и Microsoft Windows 1. Как вы, наверное, догадались, я сделал правильный выбор, но в тот момент это было далеко не бесспорное решение, в чем другие компании убедились на собственном печальном опыте.
3 После чтения этой книги ваших познаний в области .NET будет достаточно для того, чтобы самостоятельно исследовать другие альтернативы.
Я бы порекомендовал вам исследовать и оценить другие варианты в контексте ваших собственных потребностей.
Надеюсь, в первых трех главах вы нашли достаточно информации для размышления. Также хочется верить, что эти главы помогут вам сосредоточиться на своих практических потребностях при изучении дальнейшего материала. Итак, мы переходим к части 2, посвященной фундаментальным концепциям, с которыми должен ознакомиться каждый программист перед тем, как создавать свой первый компонент или приложение VB .NET.
Инфо
|