Разработчики, которые выбирают динамические языки в качестве инструмента для создания веб-сайтов и веб-приложений, часто делятся между двумя стеками: Apache и PHP Duo и платформой Ruby on Rails (хотя это упрощение большого ландшафта. Пол Грэм использует Lisp. В последние годы обе эти среды очень сильно эволюционировали, в том числе благодаря продолжающейся конкуренции. Давайте попробуем взглянуть на эти две технологии с другой точки зрения по сравнению с обычной, которая в основном X имеет эту функцию, которая позволяет вам устанавливать значения массива быстрее, чем Y! Красивая!
Было объявлено, что сравнивать PHP и Ruby on Rails несправедливо, так как один из них является языком программирования, а другой — средой полного стека. Несмотря на это, мы можем сравнивать фреймворки PHP (которые многому научились в своих первых выпусках) и Ruby on Rails, опять же, не накапливая список функций, которые также были бы загромождены различными расширениями и плагинами. Я говорю о различных подходах разработчиков PHP и Ruby Framework.
Выбор
Прежде всего, вы не можете говорить о платформах Ruby: вы должны говорить о Ruby on Rails. Основной альтернативой Rails был Merb, альтернативный стек (лучше скажу, что он лучше спроектирован), чем Ruby on Rails, который представил множество новых концепций на платформах Ruby. Например, быть независимым от ORM и не предполагать, что каждое приложение должно использовать шаблон Active Record.
В результате Merb объединился в Rails 3, теперь в бета-версии:
23 декабря мы решили положить конец дублированию и парадоксу выбора. — http://rubyonrails.org/merb
Кажется, что для мира Rails возможность выбирать между двумя различными решениями очень плохая (я начинаю звучать как Терри Чей ). Я согласен, что разделение усилий разработчика между двумя (или более) различными структурами не так уж умно , но есть и другие варианты, кроме полного включения других проектов. Разные проекты подразумевают, возможно, разные направления, что позволяет разработчикам экспериментировать с новыми парадигмами и вариантами использования (см. OSGi в Java с некоторыми реализациями, используемыми для встроенных приложений, другими для IDE и т. Д.).
Все остальные общедоступные среды Ruby пытаются быть легковесными ( менее 4 КБ ) или проводят гонку вооружений, чтобы выяснить, кто может позволить вам написать приложение hello world с самой короткой командой. Исключением является Sinatra, но это не платформа MVC.
Мир PHP использует другой подход к управлению множеством фреймворков, появившихся в ответ на повышение уровня Rails (без каламбура): совместимость. Появляются стандарты для использования компонентов из нескольких платформ. Symfony 2 будет использовать компоненты из Zend Framework, в то время как Zend Framework 2 будет интегрировать Doctrine (2), стандартный объектно-реляционный преобразователь, включенный в Symfony.
С различными версиями 2.0 фреймворков большинство проектов учатся как на допущенных ошибках, так и на шаблонах использования разработчиков, принимающих их. Один из этих уроков, на мой взгляд, заключается в том, что ни одна структура не может сделать все это хорошо и самостоятельно. Я полностью ожидаю, что следующее поколение фреймворков сделает тривиальным использование функций из других фреймворков и библиотек для реализации функциональности. — http://weierophinney.net/matthew/archives/232-Symfony-Live-2010.html
Или мы можем объединить все вместе (и Бог знает, сколько там фреймворков. Вы можете догадаться, что я в первую очередь парень из PHP). Это та же старая просьба об ортогональности: независимые компоненты, которые вы можете поменять местами, образуя множество различных комбинаций. , Я могу использовать Zend с Doctrine 1, или Zend с Doctrine 2, или Symfony с Doctrine 2, или простые старые PHP-скрипты с Doctrine 2, или Symfony с простым PDO и так далее.
магия
Не секрет, что Ruby on Rails ставит точку в соглашении о конфигурации. Надеемся, что все решается по соглашению, если вы не укажете по-другому: имена таблиц из имен классов, поля объектов из столбцов таблицы и так далее.
Немного автоматизации неплохо при настройке фреймворка, хотя я предпочитаю создавать общие настройки, которые я могу настроить позже. Однако я часто думал, что Rails заходит слишком далеко. Когда я сгенерировал свой первый проект в Ruby on Rails, я открыл свой классический класс Post (тот же старый пример « создать свой форум с двумя командами» ), и это было так:
class Post < ActiveRecord::Base
end
О, спасибо, теперь я просветленный. Нет полей, нет области, нет геттеров или сеттеров. Что здесь происходит? Где бизнес-логика?
Девиз второй итерации PHP-фреймворков — «меньше волшебства» (и «меньше моментов WTF»). Проблема с распространением соглашений по всему приложению состоит в том, что, когда что-то идет не так, становится очень трудно выяснить, что не работает правильно. Это похоже на то, как IDE развертывает ваше приложение на работающем сервере одним нажатием кнопки: кроме того, что вы не знаете, как вводить настройки в автоматизированный процесс, вы никогда не узнаете, что делает эта кнопка, и если развертывание не удастся, вы получите стандартное сообщение об ошибке. Netbeans — это интегрированная среда разработки, которая понимает все правильно: она генерирует скрипт Ant (обычно build.xml) со списком целей, таких как build и testи его кнопки просто запускают этот скрипт. Если есть проблемы, вы можете посмотреть на build.xml или даже добавить оператор отладки, а взлом автоматического кода фреймворка откроет большую банку червей.
Другим примером меньшей магии в PHP (а также в Rails, поскольку Active Record не будет навязываться разработчикам в 3.x) является текущий переход от Active Record с открытыми свойствами к сущностям на основе DataMapper, которые предоставляют геттеры. В Doctrine 2 использование методов получения позволяет структуре переопределять их в пользовательских подклассах, которые сохраняются в папке, указанной в конфигурации . Эти подклассы являются прокси-серверами — они заменяют права доступа, к которым может не быть доступа, и при вызове методов получения выполняют ленивую загрузку полей. И вы можете взломать их для отладки, если что-то не складывается.
Конечно, в PHP то же самое можно получить с помощью __get () и __set (), но тогда у нас будет следующий вариант использования:
echo $post->title; // giant database query ensues
И когда вы теряете различие между свойствами и методами, у вас появляется какая-то магия, которая собирается укусить.