Провозглашаемые преимущества ASP.NET: опыт критического анализа

Управляемый код. Именно это мы услышим прежде всего, если речь зайдёт о преимуществах ASP.NET. Кстати, код, который не в .NET — провозглашается неуправляемым. Нам должно быть страшно, и от страха перед неуправляемым кодом (образ, достойный пера Стивена Кинга) php-шникам следует переходить на ASP.NET...

Но давайте попробуем разобраться, что стоит за термином «управляемый код».

Управляемый код (managed code)
Код программы, исполняемый виртуальной машиной.NET — такой как.NET Framework CLR или Mono. При этом обычный машинный код называется неуправляемым кодом (англ. unmanaged code).
Слово управляемый здесь относится к методу обмена информацией между программой и исполняющей средой. Оно означает, что в любой точке исполнения, управляющая среда может приостановить исполнение и получить информацию, специфичную для текущего состояния.
Необходимая для этого информация представлена в управляемом коде на языке Intermediate Language и в связанных с этим кодом метаданных..
ru.wikipedia.org/

Заключение
Задача написать надежный код, учитывающий все возможные сбои, может привести в уныние. Хорошая новость: если вы создаете не оболочку и не библиотеку для использования в хостах CLR, которым необходимо обеспечить продолжительную работоспособность, скорее всего, вам не придется думать обо всем этом слишком часто. Тех, кто все же занимается именно этим, должно порадовать то, что.NET Framework 2.0 предоставляет полезный набор инструментальных средств, облегчающих эту задачу. Понимая принципы работы и использования этих систем, можно написать управляемый код, настолько же надежный, как и аккуратно написанный неуправляемый код.

Поискольку преимуществ управляемого кода выяснить не удалось, оставляю оппонентам бессмертную формулу Credo, quia absurdum и перехожу к следующему преимуществу.

Возможность использовать несколько языков программирования.
Честно признаться, не понимаю, в чём тут преимущество. Не вижу его даже для поклонника Бейсика. Любителю Бейсика столь же непросто выучить другой язык, как и выучить все отличия.NET-бейсика от привычного ему VB6 или тем более VBA.

Минусы более очевидны. От поддержки нескольких языков разработчик не получает новых возможностей. Зато система становится сложней (т.е. менее надёжной). Понижение надёжности без увеличения функциональности я считаю явным недостатком.

Компиляция.
При компиляции ASP.NET-проекта код переводится в независимое от языка и процессора представление, которое называется языком MSIL. Во время работы MSIL выполняется в контексте платформы.NET Framework, которая переводит MSIL в индивидуальные инструкции для процессора компьютера, на котором запущено приложение.

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

Так что мы не можем записать компиляцию ASP.NET-проектов как неоспоримое преимущество ASP.NET.

Разделение дизайна и программного кода. Лет восемь назад, когда пробивала себе дорогу первая версия ASP.NET (ASP.NET I), его апологеты взахлёб расписывали возможность одновременной работы дизайнера и программиста над одной и той же страницей. Уже при продвижении ASP.NET II (2005-й год) об этом преимуществе предпочитали не упоминать (а предлагаемая реализация MVC-методологии похоронила это разделение). Стало очевидным, что одновременная работа дизайнера и программиста над формами — утопия. Инструмент работы дизайнера (и WEB-дизайнера в том числе) — Adobe Photoshop. Подавляющее большинство WEB-дизайнеров отмахнётся даже от правки HTML-кода: «Я художник, а не писарь!». А такого насилия над личностью, как правка дизайна в Visual Studio, не вынесет никто из них.

(В скобках заметим, что подобную утопию пытались реализовать в шаблонизаторе для php smarty. Но использование smarty — свободный выбор разработчика, и не может быть отнесён к достоинствам или недостаткам php).

Реализация технологии MVC (Model-View-Controller)
ASP.NET 3.5 предлагает свою реализацию модной ныне технологии MVC.

Пока мне придётся помнить, что Ignorantia non est argumentum (незнание не является аргументом). Я так и не понял, чем MVC облегчает разработку.

Так что пока готов не оспаривать это преимущество. Ладно, не буду возражать против признания MVC преимуществом ASP.NET. Но надеюсь дождаться достаточно авторитетных критиков, которые скажут, что король-то голый! А пока скажу своё мнение практика: MVC — пустая блажь.

Серверные элементы управления. Этот довод я считаю самым убедительным из всех неубедительных доводов в пользу ASP.NET. Серверные элементы управления представляют собой группы HTML-элементов, которые воспринимаются WEB-сервером (MS IIS) как одно целое. Например, календарь. Он передаётся браузеру как весьма громоздкий набор тегов и кодов JavaScript, но для кода на сервере это один элемент, содержащий указанную пользователем дату.

Серверные элементы управления во многих случаях действительно сильно ускоряют разработку форм. Календарь Вы создаёте за считанные секунды и несколько минут настраиваете внешний вид. Если Вы хотите создать календарь сами, используя php и JavaScript — я гарантирую Вам два дня напряжённого труда.

Но использование серверных элементов управления («контролов»), несёт в две настолько серьёзную проблему, что я бы не пожалел дополнительного времени на разработку «нормальных» html-форм.

Речь идёт, во-первых, о читаемости приложения, во-вторых, о проблемах командной разработки.

Не так уж просто разработаться в том, как работает форма, составленная из Web-controls. Приходится перескакивать со страницы дизайна на страницу behind-класса. Не забывая, что серверные события будут отработаны только в момент сабмита (пересылки данных формы на сервер). Например, если текстовому полю Вы привязывает событие Text_changed — то обработчик этого события сработает вовсе не тогда, когда текст будет изменён. А при ближайшем сабмите. Это естественно, раз мы работаем по протоколу http. Но разработчикам Windows-приложений, начинающим разработку ASP.NET-приложения, не всегда легко это сообразить.

Но это полбеды. Серьёзная проблема возникает — когда группа разработчиков должна подготовить ряд однотипных, но разных страниц (к примеру, страницы справочников). непросто объяснить им задачу и добиться, чтоб страницы были внешне похожи. Но и это не самое неприятное.

Самое неприятное – будет представлять собой, поддержку и обновление страниц, так как, это весьма трудоёмкий процесс в силу различного стиля программирования разработчиков. И когда придётся изменить все эти страницы (скажем, ещё одну кнопку добавить), то тот, кто не использовал серверные элементы управления, поблагодарит себя за абстрактный класс и классы-потомки, сочиняющие полный HTML-код формы.

Платность как гарантия качества. Самый, пожалуй, не уместный аргумент. Достаточно ловко нам внушают, что OpenSource — любительство вроде выпиливания из фанеры лобзиком, а покупатель — вправе рассчитывать на качество и техническую поддержку.

Важно понимать, что бесплатность для разработчика не означает безопастность вообще. Для хостеров-то php платный. Т.е. мы имеем дело с другой моделью бизнеса, а не с любительством. Причём модели, доброжелательной к разработчикам php-проектов.

И важно понять, в чём заключается техническая поддержка Microsoft. Что может получить покупатель MS в плане технической поддержки

1.Обновления и «заплатки» через Интернет

2.Консультации по телефону и/или e-mail

3.MSDN и печатная литература

Но приведённый список, согласитесь, не впечатляет: php-разработчик получает обновления с php.net, консультации коллег в php-сообществах, онлайн-документация по php в открытом доступе, ну и наконец, в литературе по php нет недостатка.

ASP.NET, в отличие от php, можно использовать для разработки крупных проектов
Среди добровольных пропагандистов ASP.NET принято никак не обосновывать тезис о невозможности написания больших проектов на php. Пропагандисты изо всех сил пытаются придать ему статус очевидного. Но истинная причина нежелания предоставить аргументы – отсутствие оных.

За много лет я не нашёл ничего, подтверждающего неспособность php быть основой крупного проекта. Зато нашёл те самые крупные проекты, которых, по мнению агитаторов, быть не должно.

Как Вы думаете, Wikipedia – крупный проект? Так вот он выполнен на php, в чём Вы легко можете убедиться.

 

За что я выбираю php

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

Кроссплатформенность. php портирован практически под все распространённые операционные системы, в то время как ASP.NET ориентирован на Windows, и то не всякую, а только 2000/XP/Vista/7. Т.е. мне не нужно беспокоиться, какая операционка стоит на сервере моего клиента.

Истины ради. Существует и развивается (не фирмой MIcrosoft!) проект Mono, призванный обеспечить полноценную работу системы.NET на базе свободного программного обеспечения. Но я бы не рискнул говорить об этом проекте как о надёжной технологии, на которую можно было бы делать ставку в серьёзных проектах. Кстати, Microsoft не несёт никакой ответственности, даже моральной, за то, как будет Ваш ASP.NET-проект работать согласно Mono.

А документация по данному проекту не добавляет уверенности. Вот что, например, она говорит об инструментах разработчика, предлагаемых Mono: No documentation available on this topic (по состоянию на 5 марта 2008 года). А ASP.NET без специальных средств разработки — это солдат без ружья.

Нет чрезмерной привязки к операционной системе. Даже под Windows php может устанавливаться простым копированием, не записывая ничего в многострадальный реестр, не требуя создания специальных групп пользователей и т.п. После переустановки операционной системы Вам не потребуется долго «поднимать» php и проекты, по ним написанные. Скажем, в Windows разумно установить Apache, php и MySQL на не-системном диске. Даже после форматирования системного раздела (C:) и установки Windows заново Вам потребуется не более трёх минут для восстановления: снова инсталлировать Apache как службу
(командой apache -k install) и возобновить список виртуальных хостов (файл %System32%/drivers/etc/hosts). И всё, инцидент исчерпан...

ASP.NET взаимодействует с операционной системой (только Windows, и то не всякой) весьма тесно.

Хочу особо подчеркнуть преимущество, связанное со слабой зависимостью php от операционной системы: мне легко договориться с сисадмином фирмы-клиента.

Удачный набор функций. php предоставляет WEB-разработчику большое количество функций для решения типовых задач. Создатели php хорошо знают, какие задачи чаще всего решает разработчик WEB-приложений. В ASP.NET я не нашёл полезных функций, необходимых постоянно — при наличии огромного количества методов, которым и применения-то не придумать. Например, в WEB-приложениях часто проиходится очищать текст от тегов (это особенно актуально для форумов и гостевых книг), «квотить» строку для вставки в SQL-запрос, а также убирать этот квотинг при извлечении строки из SQL-запроса. php предоставляет нам эти функции (соответственно strip_tags(), addslashes(), stripslashes()), а вот в ASP.NET я не нашёл соответствующих методов. Разумеется, их можно реализовать на C#. Но я не настолько люблю работать...

Также отдельное спасибо авторам php за функцию var_export(). Этой функцией я легко получаю текстовое представление массива или объекта в тех случаях, когда отладчик был бы бессилен. Приведу пример: платёжная система методом POST отправляет на мою страницу данные об оплате. И если что-то идёт не так — мне легко послать самому себе текстовый дамп этого массива:

$dump=var_export($_POST,true);
mail('[email protected]', 'post',$dump);

Увы, в ASP.NET придётся писать метод, который вернёт мне текстовое представление массива или объекта.

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

Преимущества интерпретации. Кроме недостатков по сравнению с компиляцией, интерпретируемые языки имеют весьма ощутимые преимущества.

В первую очередь это возможность собирать и запускать на выполнение строку программного кода (функцией eval()), что даёт целый ряд возможностей. Например, сделать методики расчёта стоимости различных услуг данными, хранящимися в базе данных.

Также очень удобно, что, имея переменную, хранящую название другой переменной, свойства или метода – можно легко обратиться к переменной/свойству и вызвать метод.

Если переменная $a равна "b", то к переменной $b можно обратиться:
$$a

Если переменная $a равна "p", то к cвойству p можно обратиться:
$object->$p

Если переменная $a равна "m", то метод m можно вызвать:
$object->$m()

Эти возможности мне нужны весьма часто, а использовать их, скажем, в C# затруднительно: приходится создавать unsafe-блоки для указателей на переменные (C# не очень хорошо приспособлен для работы с указателями), а для методов – сочинять классы-делегаты.

Прозрачная привязка проекта к файловой системе. И как следствие — нет необходимости в специальных средствах разработки (вроде Visual Studio). Иными словами, в php-проекте нет конструкций, для визуализации и редактирования которых требовался бы особый редактор.

Что же мы видим в ASP.NET? Не так уж просто сообразить, например, как связаны пространства имён (namespaces) и расположение файлов на диске. В итоге бывает, что классы не видят друг друга. Приведу пример.

Есть ASP.NET хостинг. Пытаемся (для экономии сил и времени) разместить два проекта на одном хостинге. В случае php никакой проблемы нет.

В случае же ASP.NET выясняется, что оба проекта начинают вести себя в папке хостинга, как на коммунальной кухне. Они желают иметь в корневом каталоге аккаунта свои файлы и папки — иначе страницы проекта как-то демонстративно не видят друг друга.

Простота настройки Apache, php,MySQL. Все настройки содержатся в тектовых ini-файлах. Все параметры откомментированы. И что особенно ценно: если чтьо-то идёт не так, Вы почти всегда получите сообщение, где ясно изложена проблема, указана строка ini-файла, которая «не понравилась». Есть, увы, исключения, но именно те, которые подтверждают правило: настройки и сообщения об ошибках LAMP понятны.

Несмотря на то, что продукт Visual Studio Express предлагается такой солидной корпорацией, как Microsoft, даже при попытке установки данного приложения возникают различные сбои:

В сравнении Visual Studio Express более надёжным и простым подходом, не требующим длительной установки и наладки программных сред, является разработка web-страниц на php.

Совместимость «снизу вверх».Переход php-проекта на новую версию php возможен либо вообще без изменений (именно этим мне запомнился переход с php 4.x на php 5.x), либо с минимальными доработками, связанными, как правило, с изменениями настроек по умолчанию (не буду долго останавливаться на том, что полагаться на настройки по умолчанию – дурной тон в программировании). А случае с ASP.NET (о переходе с ASP.NET 1.0 на ASP.NET 2.0) мы видим, что проект надо полностью переделать. Часть этой работы возьмёт на себя «колдун» (насколько хорошо он сработает – не проверял).

Простота формирования текстовых строк. Отдельное спасибо разработчикам php за:

· возможность вставлять в двойные кавычки имена переменных и свойств:

· $ w ='world';

· print "Hello $w!"; //Напечатает Hello world!

или

$ this ->w='world';

print "Hello $this->w!"; //Напечатает Hello world!

· возможность ввода большого текста с кавычками методом heredoc:

· $ html =<<<EOD

· <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"

· "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

· <html xmlns="http://www.w3.org/1999/xhtml">

· <head>

· <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

· <title> new document </title>

· <meta name="keywords" content="" />

· <meta name="description" content="" />

· </head>

· EOD;

Жёлтым маркером отмечены делимитеры, в которые заключён текст.

 

Подведём итоги

Стараясь быть максимально объективным, я изложил причины, по которым предпочитаю разрабатывать проекты на php, а не на ASP.NET. Но я вовсе не желал подвести к выводу, что на ASP.NET очень трудно или невозможно сделать хороший проект. Я лишь хотел предостеречь от рекламных восторгов, от отношения к ASP.NET как к чему-то изумительному, позволяющему быстро и легко делать серьёзные проекты.