|
PHP или ASP что изучать
|
||
|---|---|---|
Гость
|
||
|
Сравнение php и ASP.NET
Вопрос о выборе технологий перестаёт быть сугубо техническим, когда один из возможных вариантов — .NET. В случае WEB-приложений речь идёт, конечно же, об ASP.NET (не путайте, пожалуйста, его с ASP — весьма убогим предшественником ASP.NET). Который, согласно рекламным статьям Microsoft, просто обязан стать стандартом разработки сложных WEB-приложений. Ведь это «управляемый код», MSF-методология, серверные элементы управления... И мне уже не раз приходилось отвечать на вопрос, почему же я разрабатываю свои программы не на этом замечательном средстве. А значит, мне не раз придётся отвечать на этот вопрос. Что ж, подготовлю себе пособие для ответа. Я изучил ASP.NET, в том числе на семинарах, организованных партнёрами Microsoft (см. мой отчёт об одном из них). И... лишь укрепился в своём выборе LAMP (Linux, Apache, MySQL, Php) как платформе для разработки своих WEB-приложений, главным из которых является, конечно же, «ТурМенеджер». Но свой ответ я постараюсь дать максимально объективно. Кстати, именно объективности не хватает статьям, сравнивающим эти две технологии. Дискуссии на эту тему оживляют в памяти картину Перова «Спор о вере». Я же постараюсь исключить субъективизм. Например, мне очень нравится документация по php; но я в ужасе от MSDN, представляющейся мне лемовскими сепульками, сепулькариями и сепулением. Но я встречал очень серьёзных специалистов (и не в единственном числе!), которые при мне легко находили нужную информацию в MSDN. Значит, я снимаю аргумент про документацию как субъективный. И также поступаю со многими другими своими аргументами. Оставляю только те, которые не зависят от моих пристрастий и предпочтений. Так начнём же повесть сию... Очевидные преимущества ASP.NET Типизация. Языки программирования ASP.NET имеют строгую типизацию данных. Это безусловно выигрышный момент по сравнению с нетипизированным php: меньше будет логических ошибок, которые весьма трудно находить и исправлять. Некоторым утешением для сторонников php является возможность привести переменную к нужному типу — но увы, присвоение переменной, приведённой к целому типу, строкового значения не вызовет даже предупреждения с стороны интерпретатора. Маркетинговая политика Microsoft. Если Вы пишете на ASP.NET — на Вашей стороне мощная рекламная машина Microsoft, а также партнёрские программы этой фирмы. Без заказов Вы не останетесь. Очевидные преимущества php Официальная бесплатность для разработчика Вы можете легально скачивать с сайта www.php.net дистрибутив php, не чувствуя себя пиратом. То же самое касается смежных технологий. Значит, я не вовлеку заказчика в дополнительные траты (ну или не подтолкну к использованию «нелицензионки»). В то же время ASP.NET и смежные технологии — очень даже платные. Доступность дистрибутивов. Дистрибутивы LAMP измеряются в десятках мегабайт (а не в DVD-дисках, как Windows/IIS/Visual studio/MS SQL Server) и доступны в на сайтах разработчиков. Т.е. php — это «праздник, который всегда с тобой». Open source (открытый код) Вы можете внести изменения как в движок php, так и в набор стандартных функций самостоятельно (разумеется, если умеете программировать на С++). Это бывает полезно, когда быстродействие критично: скомпилированные функции выполняются быстрее, нежели написанные на php. Кстати, это хороший способ защитить приложение от несанкционированного использования. Кстати, это и возможность аудита: можно убедиться, что в даной технологии нет «люков» для шпионажа. Мекий и средний бизнес может не беспокоиться на этот счёт, а вот большой бизнес и государственныен структуры должны неуютно себя чувствовать, ставя на серверы программы с закрытым кодом. Отсюда стремление Китая и Индии перевести свои госструктуры на Linux. Что особенно важно — аудитом кода занимаются программисты всего мира, способствуя устранению уязвимостей. * * * Итак, мы отметили достоинства обеих технологий, представляющихся мне очевидными и бесспорными. Со всеми остальными доводами обеих сторон нужно разбираться. Что ж, приступим. Сравнение возможностей: стратегический паритет Поскольку обе технологии ограничены довольно простым протоколом HTTP и языком разметки HTML — их возможности примерно равны. Все задачи, решаемые в рамках одной техногогии, столь же успешно решаются и в рамках другой. Можно спорить лишь о большем или меньшем удобстве предлагаемые технологиями решений — но мы воздержимся от споров о вкусах. Таким образом, ни php, ни ASP.NET не дают технологического преимущества WEB-проекту. Различия проявляются в стоимости и трудоёмкости разработки и эксплуатации проекта. В этих показателях, по моему убеждению, php значительно выгодней ASP.NET. А преимущества ASP.NET в области разработки и поддержки, провозглашаемые рекламой, в основном являются, увы, не более чем рекламой. Обсудить которую, тем не менее, необходимо. Провозглашаемые преимущества ASP.NET: опыт критического анализа Управляемый код. Именно это мы услышим прежде всего, если речь зайдёт о преимуществах ASP.NET. Кстати, код, который не в .NET — провозглашается неуправляемым. Нам должно быть страшно, и от страха перед неуправляемым кодом (образ, достойный пера Стивена Кинга) php-шникам следует переходить на ASP.NET... Но давайте попробуем разобраться, что стоит за термином «управляемый код» . Управляемый код (managed code) Код, который запускается под "contract of cooperation" в среде выполнения. Управляемый код должен содержать метаданные, необходимые среде выполнения для того, чтобы обеспечить работу сервисов, таких, как управление памятью, межъязыковая интеграция, проверка доступа кода и автоматическое управление жизненным циклом объектов. Весь код, представленный в виде промежуточного языка, выполняется как управляемый код. http://www.gotdotnet.ru/DotNet/Vocabulary/default.aspx Управляемый код (managed code) Код программы, исполняемый виртуальной машиной .NET — такой как .NET Framework CLR или Mono. При этом обычный машинный код называется неуправляемым кодом (англ. unmanaged code). Слово управляемый здесь относится к методу обмена информацией между программой и исполняющей средой. Оно означает, что в любой точке исполнения, управляющая среда может приостановить исполнение и получить информацию, специфичную для текущего состояния. Необходимая для этого информация представлена в управляемом коде на языке Intermediate Language и в связанных с этим кодом метаданных.. ru.wikipedia.org/ Вам стало понятно, что такое управляемый код? Если да, то я Вам завидую. Но мне придётся обратиться к статьям, трактующим это понятие для непонятливых. Итак, статья Написание надежного управляемого кода в .NET Framework 2.0. Автор — Стивен Тауб (Stephen Toub), технический редактор журнала «MSDN Magazine», в котором также ведет колонку «Вопросы .NET». Заключение Задача написать надежный код, учитывающий все возможные сбои, может привести в уныние. Хорошая новость: если вы создаете не оболочку и не библиотеку для использования в хостах CLR, которым необходимо обеспечить продолжительную работоспособность, скорее всего, вам не придется думать обо всем этом слишком часто. Тех, кто все же занимается именно этим, должно порадовать то, что .NET Framework 2.0 предоставляет полезный набор инструментальных средств, облегчающих эту задачу. Понимая принципы работы и использования этих систем, можно написать управляемый код, настолько же надежный, как и аккуратно написанный неуправляемый код .[Выделено мной — Ю.М.] Поискольку преимуществ управляемого кода выяснить не удалось, оставляю оппонентам бессмертную формулу Credo, quia absurdum и перехожу к следующему преимуществу. Компиляция. Компиляция имеет неоспоримое преимущество перед интерпретацией: быстродействие. В самом деле, при компиляции исполняемый (машинный) код сохраняется на диске, а значит, при запуске этого файла не тратится время на трансляцию (преобразование исходного кода в машинный). Когда я выслушиваю от апологета ASP.NET этот довод, то добродушно спрашиваю: «А где же этот самый исполняемый файл, который образовался в результате компиляции?». С нескрываемой досадой собеседники отвечали, что при компиляции ASP.NET-проекта... никаких исполняемых файлов не создаётся. Больше того. Когда мы пытаемся сравнить быстродействие, меня сразу предупреждают, что при первом заходе моего броузера на страницу ASP.NET оная будет заметно «тормозить», зато при повторных заходах будет грузиться очень быстро, потому что, оказывается, при моём первом заходе на страницу она... компилируется. Странная какая-то компиляция, не находите? А вот я нахожу, что это больше похоже на интерпретацию с последующим кешированием. Снова преимущество ASP.NET не вдохновило меня. Так что идём дальше. Разделение дизайна и программного кода. Лет пять назад, когда пробивала себе дорогу первая версия ASP.NET (ASP.NET I), его апологеты взахлёб расписывали возможность одновременной работы дизайнера и программиста над одной и той же страницей. Уже при продвижении ASP.NET II (2005-й год) об этом преимуществе предпочитали не упоминать. Стало очевидным, что одновременная работа дизайнера и программиста над формами — утопия. Инструмент работы дизайнера (и WEB-дизайнера в том числе) — Adobe Photoshop. Подавляющее большинство WEB-дизайнеров отмахнётся даже от правки HTML-кода: «Я художник, а не писарь!» . А такого насилия над личностью, как правка дизайна в Visual Studio, не вынесет никто из них. (В скобках заметим, что подобная утопия воплотилась в шаблонизаторе для php smarty. Но её использование — свободный выбор разработчика, и не может быть отнесён к достоинствам или недостаткам php). Это же преимущество имеет ещё одну формулировку, а значит, и другое возражение. Визуальный конструктор форм. Вам предагают отказаться от HTML-вёрстки форм, заменив её рисованием с помощью встроенного в Visual Studio визуального редактора. Моё глубокое убеждение: не следует отказываться от HTML-вёрстки. Если Вы создаёте страницы в визуальном редакторе — Вы теряете возможность управления формой через правку текста (HTML-кода), теряете управление дизайном с помощью CSS-файлов, зато приобретаете мёртвую привязку к среде разработки (Visual Studio). Серверные элементы управления. Этот довод я считаю самым убедительным из всех неубедительных доводов в пользу ASP.NET. Серверные элементы управления представляют собой группы HTML-элементов, которые воспринимаются WEB-сервером (MS IIS) как одно целое. Например, календарь. Он передаётся броузеру как весьма громоздкий набор тегов и кодов JavaScript, но для кода на сервере это один элемент, содержащий указанную пользователем дату. Серверные элементы управления во многих случаях действительно сильно ускоряют разработку форм. Календарь Вы создаёте за считанные секунды и несколько минут настраиваете внешний вид. Если Вы хотите создать календарь сами, используя php и JavaScript — я гарантирую Вам два дня напряжённого труда. Но если Вы грамотно писали свой календарь в течении двух ней — Вы можете забыть о проблемах работы с календарём раз и навсегда. А вот тому, кто использовал в ASP.NET-проекте серверный элемент управления Calendar, я не могу этого обещать. Слишком вероятно изменение набора серверных элементов в следующих версиях ASP.NET. Microsoft Solutions Framework (MSF). Это предлагаемая Microsoft методология создания программных решений, которая описывает управление людьми и рабочими процессами в процессе разработки решения под бизнес-требования заказчика. Vusual Studio 2005 содержит средства поддержки этой методологии: Visual Studio 2005 Team System. Я почитал описание MSF. желающие могут их скачать со страницы www.microsoft.com/Rus/Msdn/msf/Default.mspx. Честно признаться, я не верю, что эта методология действительно может помочь при работе над IT-проектом, выполняемым на заказ. И вот почему. Вот как данная концепция схематически отражает процесс разработки:  Кстати, эта схема напоминает мне этапы согласно ГОСТ 19.102-77 «Единая система программной документации. Стадии разработки»: Техническое предложение → Эскизный проект → Технический проект → Рабочий проект → Внедрение «Вот скажут — это ново... А это уже было в веках...» (Экклесиаст). Из этой схемы и описания к ней следует, что после утверждения концепция не претерпевает изменений. И что на этапе внедрения не вносятся изменения в программу. Мне ближе мысли, изложенные в классической книге Фредерика Брукса «Мифический человеко-месяц, или как создаются программные системы»: Правда заключается в том, что клиенты не знают, чего хотят. Обычно они не знают, на какие вопросы нужно дать ответ, и почти никогда не задумываются над задачей настолько детально, как это нужно указать в спецификации... Я пойду дальше и стану утверждать, что на практике клиенты, даже вместе с инженерами-программистами, не в состоянии указать полно, строго и корректно точные требования к современному программному продукту, прежде чем будут созданы и опробованы какие-либо версии продукта, спецификации к которому они составляют Глава 16 То, что пишет Брукс, я много раз испытал на себе, выполняя заказы. Именно на этап внедрения приходилась веха «окончательное утверждение концепции». Так что я не готов работать согласно MSF, а значит, соответствующие опции Vusual Studio мне ни к чему. Платность как гарантия качества. Самый, пожалуй, остроумный аргумент. Достаточно ловко нам внушают, что OpenSource — любительство вроде выпиливания из фанеры лобзиком, а покупатель — вправе рассчитывать на качество и техническую поддержку. Важно понимать, что бесплатность лдля разработчика не означает беспластность вообще . Для хостеров-то php платный. Т.е. мы имеем дело с другой моделью бизнеса , а не с любительством. Причём модели, доброжелательной к разработчикам php-проектов. И важно понять, в чём заключается техническая поддержка Microsoft. Что может получить покупатель MS в плане технической поддержки Обновления и «заплатки» через Интернет Консультации по телефону и/или e-mail MSDN и печатная литература Если я что-то упустил — пишите коментарий, я дополню. Но приведённый список, согласитесь, не впечатляет: php-разработчик получает обновления с php.net, консультации коллег в php-сообществах, онлайн-документация по php в открытом доступе, ну и наконец, в литературе по php нет недостатка. ASP.NET, в отличие от php, можно использовать для разработки крупных проектов Среди добровольных пропагандистов ASP.NET принято никак не обосновывать тезис о невозможности написания больших проектов на php. Пропагандисты изо всех сил пытаются придать ему статус очевидного. Но истинная причина нежелания предоставить аргументы – отсутствие оных. За много лет я не нашёл ничего, подтверждающего неспособность php быть основой крупного проекта. Зато нашёл те самые крупные проекты, которых, по мнению агитаторов, быть не должно. Как Вы думаете, Wikipedia – крупный проект? Так вот он выполнен на php, в чём Вы легко можете убедиться. Вот мы и рассмотрели все преимущества, о которых я услышал в рекламе. Если я что-то упустил — пишите комментарий. А мы переходим к преимуществам php. За что я выбираю php Не буду повторяться и долго говорить о доступности дистрибутивов, открытости кода и официальной бесплатности php. Также, как и обещал, постараюсь не быть предвзятым и приводить только те аргументы, которые можно проверить. Кроссплатформенность. php портирован практически под все распространённые операционные системы, в то время как ASP.NET ориентирован на Windows, и то не всякую, а только 2000/XP/Vista. Т.е. мне не нужно беспокоиться, какая операционка стоит на сервере моего клиента. Истины ради . Существует и развивается (не фирмой 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(), htmlspecialchars(), addslashes() , stripslashes()), а вот в ASP.NET я не нашёл соответствующих методов. Разумеется, их можно реализовать на C#. Но я не настолько люблю работать... Также отдельное спасибо авторам php за функцию print_r() . Если я чувствую, что что-то не то происходит с массивом или объектом, я этой функцией вывожу его текстовое представление на экран. Увы, в 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? Данные, необходимые для работы проекта, хранятся не только в файлах проекта. Некоторые из них хранятся неизвестно где. Вот парочка примеров. Подключаем к проекту библиотеку классов, по умолчанию не подключённую. Переносим проект на другой сервер — и оказывается, надо опять средствами Visual Studio подключать эту библиотеку. Хорошо, если она одна... Если мы в текстовом редакторе создали класс, то при его копировании в папку проекта сталкиваемся с тем, что остальные файлы проекта этот класс не «видят». Класс нужно вставить через Visual Studio, которая где-то сохранит информацию о том, что в указанном пространстве имён (namespace) есть такой класс. Итак, мы не можем формировать ASP.NET-проект без Visual Studio. В то же время php-проект хранит в своих файлах всю необходимую информацию, которая удобочитаема и доступна для редактирования (в т.ч. программного). Простота настройки Apache, php,MySQL. Все настройки содержатся в тектовых ini-файлах. Все параметры откомментированы. И что особенно ценно: если чтьо-то идёт не так, Вы почти всегда получите сообщение, где ясно изложена проблема, указана строка ini-файла, которая «не понравилась». Есть, увы, исключения, но именно те, которые подтверждают правило: настройки и сообщения об ошибках LAMP понятны. А вот захотел я протестировать Visual Studio Express. Скачиваю. Запускаю установку. Выскакивает сообщение:  И вот что теперь делать? Ну я-то плюну на тестирование и займусь своими php-проектами. А каково тому, который в офисе клиента громоздит всё необходимое для работы ASP.NET? Когда я ездил сдавать проект, сделанный на фреймворках MS — я почти физически чувствовал, что что-то сработать не должно. Откажется устанавливаться, потому что не скачана какая-то заплатка к Windows. Откажется работать, потому что какая-то служба Винды не запущена (или запущена, но работает как-то странно). Начнёт работать, но выдаст ошибки, описание которых никак не поможет. Настройки, которые вроде работали, слетят после перезагрузки сервера. А если админ решит переустановить Windows — пиши пропало. Совместимость «снизу вверх».Переход php-проекта на новую версию php возможен либо вообще без изменений (именно этим мне запомнился переход с php 4.x на php 5.x), либо с минимальными доработками, связанными, как правило, с изменениями настроек по умолчанию (не буду долго останавливаться на том, что полагаться на настройки по умолчанию – дурной тон в программировании). А случае с ASP.NET (см. статью на английском языке о переходе с ASP.NET 1.0 на ASP.NET 2.0) мы видим, что проект надо полностью переделать. Часть этой работы возьмёт на себя «колдун» (насколько хорошо он сработает – не проверял). Другие среды разработки от Microsoft также создают много головной боли при переходе проекта на новую версию. Вот, например, недавно MS Access перестал поддерживать ODBCDirect, заставив меня порадоваться, что моя программа ушла с Аксесса. Честно говоря, не знаю, как теперь работать с MySQL через MS Access. И счастлив, что мне уже не нужно это лихорадочно узнавать. Подведём итоги Стараясь быть максимально объективным, я изложил причины, по которым предпочитаю разрабатывать проекты на php, а не на ASP.NET. Но я вовсе не желал подвести читателя к выводу, что на ASP.NET очень трудно или невозможно сделать хороший проект. Я лишь хотел предостеречь от рекламных восторгов, от отношения к ASP.NET как к чему-то изумительному, позволяющему быстро и легко делать серьёзные проекты. И в заключение своей статьи пожелаю читателю сделать осознанный выбор, а не навязываемое рекламой решение. Удачи! |
||
| 25.08.2008, 14:23:52 |
|
|
