Ответ 1
CakePHP похож на дешевый, развращенный Ripoff Rails. Он пытается быть похожим на Rails, не делая ничего из того, что делает Rails отличным. Кажется, он похож на меня.
CakePHP имеет помощник Ajax, который делает что-то похожее на вспомогательные методы, связанные с Ajax, в Rails, поэтому да, в некотором роде, это также верно.
Но CakePHP - это действительно бесполезное упражнение: его авторы написали его, поэтому им не нужно было изучать Ruby, хотя изучение Ruby и Rails вместе, вероятно, проще, чем выяснение чудовищного беспорядка, который является CakePHP.
(Это происходит от кого-то, кто делает CakePHP на своей дневной работе.)
Так как y'all спросил, моя самая большая жалоба на CakePHP заключается в том, как ему удается полностью уничтожить удобства объектно-ориентированного программирования: конечно, он реализует шаблон Active Record точно так же, как Rails, но он заставляет вас пройти структуры данных.
Я чувствую, что любой логический человек будет реализовывать ORM, используя ошибки и динамическую загрузку свойств в объекты, что и делает ActiveRecord (библиотека Rails). Вся идея установки переменной-члена, называемой $recursive, чтобы определить, какие отношения для загрузки являются просто ошибочными.
Основываясь на PHP, тоже довольно смертельно; вы ничего не можете сделать с глобальным состоянием, вы должны зависеть от mod_rewrite, вы платите штраф за запуск при каждом запросе. Конечно, есть оптимизация для любой среды, которую вы используете, но все же. Люди говорят, что Ruby работает медленно, но мои собственные приложения Rails работают быстрее, чем их эквиваленты CakePHP, последний раз я проверял. Я признаю отсутствие данных об этом.
Хуже всего, ошибки в CakePHP просто убивают его для меня. Я мог бы рассказать о нескольких историях о
- время, которое мы провели два дня, выяснив, почему CakePHP отказался подключиться к правильному узлу базы данных
- время, в течение которого половина наших страниц была пуста, из-за того, что потолок памяти из-за использования слишком большого количества компонентов
- количество кода, которое живет в нашем AppController, потому что каждая загрузка компонента стоит несколько мегабайт памяти
- черное искусство массирования структур данных для правильной работы XML файла.
- как мы проследили пустой тег
<javascript>, который отображается в конце каждой страницы