Критика и сравнение Ruby on Rails с другими фреймворками

Существует достаточно много фреймворков, необходимых для разработки веб-приложений, используя самые различные языки программирования. Понятие о наборе функций, который должен реализовывать именно такой фреймворк устоялось более или менее: средства валидации форм, разделение аспектов разработки при помощи паттерна MVC, средства для работы с Базой Данных, отображение URL на методы контроллера, объектно-реляционное отображение данных и др. Имеет смысл воспользоваться другими библиотеками в случае, когда фреймворк не в полном объеме реализует такой набор. Именно поэтому сравнение фреймворков по набору функций не имеет никакого смысла.

Одной из самых важных отличительных черт Ruby on Rails, на которую популяризаторы и разработчики данного фреймворка делают очень большой упор, является быстрая и довольно простая разработка веб-приложений, что дает некий прирост к общей стоимости разработанного продукта. Этого можно добиться, если использовать свойства языка программирования Ruby: ООП, динамическая типизация, способность генерации кода на этапе выполнения, более чем удобные конструкции для управления. Но само собой, все это понижает скорость работы. Дополнительные затраты, которые идут на вычислительные ресурсы, могут окупиться лишь снижением стоимости разработки веб-приложения.

На данный момент язык программирования Java и другие технологии, которые ему сопутствуют, является одним из самых популярных индустриальных стандартов. Давайте сравним фреймворки, которые основаны на Ruby on Rails и Java.

Контроллер. Для указания кода, позволяющего выполнять то или иное действие, программисту в Struts следует написать XML-дескриптор, который содержит отображение URL на классы Action. Ruby on Rails, в свою очередь, находит соответствующий ему ActionController и метод языка, который руководствуется общепринятыми разумными правилами.

Действия. Код каждого действия в Struts должен храниться отдельно, в разных классах, которые наследует класс Action. Это было специально сделано, поскольку условия  статистической типизации дают возможность вызывать действия различного рода единообразно, что позволяет использовать единый интерфейс Action. Но все же, проще и логичнее было бы использовать несколько действий, которые производятся над одним объектом (delete, list, save), используя методы одного класса, как это реализовано в Rails.

Сохраняемость. Одним из самых популярных и известных фреймворков, позволяющих хранить объекты в реляционной Базе Данных в мире Java считается Hibernate. ActiveRecord, который входит в Rails, реализует подобный функциональный набор.

Для задания сохраняемого объекта в Hibernate, следует: 1) описать данный класс объекта, при этом задать все поля, а также методы аксессоры для них; 2) описать, как будет отображаться таблица на объект в XML-дескрипторе. В Ruby on Rails это требование отсутствует. Ruby on Rails определяет автоматически, что класс Order, который был унаследован от ActiveRecord::Base, показывает таблицу orders, и в самостоятельном режиме из базы подхватывает имена полей класса, а также задает методы –аксессоры.

Масштабирование. Масштабируемость никак не связана со скоростью выполнения. Она означает лишь возможность получения 100%-ного прироста производительности, если добавить некоторые дополнительные ресурсы (например, еще один сервер). Приложения, которые написаны на Ruby on Rails, масштабируются тем же самым образом, как и на Perl, PHP, Java. То есть зависит от того, предусмотрено ли масштабирование в самом приложении.

Производительность. Скорость выполнения на Java больше, чем на Ruby on Rails. Это все связано с интерпретируемого языка и тем, что огромное количество действий идет на выполнение этапа. Соответственно, данную проблему можно решить кэшированием. Но, скорость отличается не на порядки, а некоторые из разработчиков умудряются даже превзойти показатели Java. Кроме всего этого, к выпуску готовится совершенно новый, по скорости оптимизированный интерпретатор Ruby on Rails.