Symfony против CakePHP [закрыто]
Проблема, с которой я столкнулся, заключается в том, что мой вопрос о различиях между Symfony и CakePHP был закрыт, так как, по мнению сообщества, он не соответствует формату вопросов и ответов. В частности, мне указали, что ожидаются фактические, основанные на обоснованиях ответы, в то время как мой вопрос, вероятно, приведет к спорам или длительным обсуждениям.
Я понимаю, что оба фреймворка имеют свои сильные и слабые стороны, и их выбор может зависеть от множества факторов, таких как тип проекта, личные предпочтения и опыт команды. Однако я хотел бы получить более четкое объяснение концептуальных различий между Symfony и CakePHP — возможно, кто-то сможет предоставить факты или ссылки, которые помогут пролить свет на этот вопрос. Если есть возможность улучшить вопрос и, возможно, снова его открыть, прошу поделиться советами по этому поводу.
5 ответ(ов)
CakePHP и Symfony — это два популярных фреймворка для разработки веб-приложений на PHP, и многие разработчики задаются вопросом, в чем же их отличия. Вот некоторые ключевые моменты, которые стоит учесть:
CakePHP:
- Философия: Философия CakePHP схожа с Ruby on Rails, что делает его интуитивно понятным для разработчиков, знакомых с концепциями MVC.
- Подходит для: CakePHP лучше подходит для средних проектов благодаря своей простоте и быстроте разработки.
- Скорость обучения: Этот фреймворк быстрее для изучения, что удобно для новичков.
- Легковесность: CakePHP легче по сравнению с Symfony, что позволяет разработчикам быстро начать проект.
- Взаимодействие с базой данных: В CakePHP используется CRUD для работы с базами данных, что делает операции с данными простыми и понятными.
- Тестирование: CakePHP поддерживает PHPUnit, что позволяет легко проводить тестирование кода.
- Интересные функции: У CakePHP есть такие интересные инструменты, как Bake и возможность использования шаблонов (scaffolding) для быстрого создания приложений.
Symfony:
- Философия: Философия Symfony такова, что каждая версия отличается от предыдущей, что может потребовать времени на адаптацию.
- Скорость обучения: Symfony изучается медленнее, особенно для новичков, из-за своей гибкости и большой функциональности.
- Подходит для: Этот фреймворк лучше всего подходит для крупных проектов, где нужна высокая степень кастомизации и масштабируемости.
- Взаимодействие с базой данных: Symfony использует Doctrine для взаимодействия с базой данных, что предоставляет разработчикам мощные инструменты ORM.
- Тестирование: Symfony также использует PHPUnit для тестирования, что обязательно для обеспечения стабильности приложения.
- Интересные функции: В Symfony интерес представляют Bundles и шаблоны, которые позволяют создавать reusable компоненты и расширять функциональность приложения.
В общем, выбор между CakePHP и Symfony зависит от ваших потребностей и опыта. Если вы ищете более простой и быстрый фреймворк для средних проектов, CakePHP может быть лучшим выбором. Если же вам нужен мощный инструмент для разработки крупных и сложных приложений, Symfony будет предпочтительнее.
Некоторые из упомянутых выше утверждений о CakePHP и его ограничениях просто не соответствуют действительности. Запросы вполне выполнимы – нужно лишь знать, как это сделать. "Автомагия" CakePHP действительно впечатляет: вы можете быстро начать разработку. Это БЫСТРЕЙШИЙ фреймворк для разработки, и не зря он так схож с RoR, который, как известно, имел большой успех и популярен в сообществе. В CakePHP есть более продвинутые возможности для получения данных в другом формате и выполнения более сложных запросов с помощью нескольких коротких вызовов методов и заданных параметров массивов.
Однако, насколько мне известно, ни один другой фреймворк не предлагает столько "автомагических" методов и классов. CakePHP берет на себя самые распространенные задачи и предоставляет простой способ их решения. Если вы действительно умны, вы будете делать большую часть своего кода на уровне модели и использовать файлы app_model и app_controller, что сделает ваше приложение очень эффективным.
Консоль тоже отличная и постоянно развивается. Сообщество просто потрясающее, и существует множество вкладов, которые помогут вам начать работу еще быстрее. Вы можете буквально спроектировать приложение и затем "перемещать" "элементы" на места, чтобы очень быстро создать приложение, поскольку большинство из необходимого уже доступно. Этого нет ни в одном другом фреймворке, где вам обычно требуется гораздо больше времени на кодирование.
Наконец, хотя документация была не на высоте, сейчас она значительно улучшилась, и хотя CakePHP получил некоторые жесткие отзывы в период отсутствия документации и версии 1.1, он все равно оставался хорошим, просто его сильно недооценивали. С выходом версии 1.2 и в ожидании Cake2 и Cake3 мнения людей начнут меняться.
Я использую CakePHP с версии 1.1 и верю в него. Я применял его для огромных корпоративных сайтов, которые получают миллионы посещений в день... Мы вышли за рамки таких решений, как WordPress и Drupal. Когда вы достигаете такого уровня для CMS-приложений, я очень рад, что использую CakePHP. Аналогично, Symfony и CodeIgniter помогут вам с масштабированием. Ничего плохого о них сказать не могу. Я лишь могу утверждать, что с CakePHP у вас уйдет меньше времени на кодирование, и вы найдете более крупное сообщество (и супер-дружественный IRC-канал).
Я рассматриваю и документирую свои ответы на комментарии о CakePHP и о некоторых его (в некоторых случаях вполне оправданных) недостатках.
Большие вебсайты работают на CakePHP, такие как Mozilla Addons, Scratch от MIT и Hot Scripts. Более полная информация есть в конце сайта CakePHP (http://cakephp.org). В любом случае, хороший разработчик должен уметь создать масштабируемый вебсайт с использованием фреймворка, если этот фреймворк не является совершенно несуразным (CakePHP не так уж несуразен 😄).
Верно, что нет одного очень хорошего (бесплатного) туториала по CakePHP, который охватывал бы все особенности фреймворка, но документация очень хорошо структурирована и подробна. Все, что остается непонятным, можно уточнить в Google Группах и на IRC, и мы приветствуем любые изменения и исправления в документации. Документация — это не только вопрос для основных разработчиков, ведь многие вещи специфичны для приложений, и люди придумывают интересные советы и уловки, поэтому приглашаем всех участвовать (не только комментировать!). Естественно, вся информация модерируется, так что большая часть спама не появляется.
Код модульный, вы можете добавлять новый код, который заменяет основную функциональность. Большая часть кода — это просто классы PHP. Верно, что написание такой функциональности может быть обременительным, и я не пробовал использовать альтернативные классы в качестве заполняющих. Да, CakePHP не поддерживает другие ORM, так что вы привязаны к стандартному, но это должно измениться в Cake3, который сможет смешивать и сочетать любые другие классы PHP по вашему усмотрению (включая поддержку Propel и Doctrine).
CLI очень хорош, и его легко расширить для поддержки специфичных для приложения функций. Например, я недавно разработал плагин для оболочки, который автоматически устанавливает любые другие плагины CakePHP, которые я индексировал на GitHub. Мне потребовалось около 5 часов, чтобы создать нечто очень удобное и гибкое. Уверен, что такая функциональность существует для Symfony, и она присутствует для RoR 😃
Что касается того, является ли CakePHP «похожим на Rails», в чем-то да, а в чем-то нет. Многие вещи похожи, они все-таки MVC-фреймворки, и CakePHP придерживается подхода «Конвенции против Конфигурации». Поддержка PHP4 затрудняет более приятный синтаксис, который, безусловно, имеет Symfony благодаря поддержке только PHP5, но он все равно остается очень удобным и интуитивно понятным. Фреймворк не предоставляет каждые возможности Rails «из коробки», так как он не является простым клоном. CakePHP — это фреймворк, а не библиотека (привет, Zend), так что он не предложит всего изначально.
Согласен, генерация представлений в CakePHP немного странная. Она значительно улучшится в версиях 1.3 и 2.0. Будет поддержка пользовательских шаблонов для каждой модели, вида и контроллера (в отличие от только одного типа представления, как это сделано сейчас). Также есть набор задач оболочки на GitHub от пользователя neilcrookes, который автоматически создает только определенные типы представлений (включая только административные), которые можно использовать в сочетании с пользовательскими шаблонами для достижения желаемого результата. CSS-стилизация также помогает 😃 Но это уж точно то, что можно улучшить.
CakePHP принимает множество различных параметров в методах Modelfind, хотя в некоторых случаях может быть полезно использовать «сырые» SQL-запросы. Метод Modelfind() очень гибкий и не подводил меня при создании сложных запросов. Полагаю, это связано с тем, что я довольно уютно чувствую себя с ORM, что, безусловно, всегда занимает время.
Валидация форм, логически, должна находиться на уровне модели, ведь именно там выполняются действия, связанные с базой данных. Я полагаю, вы можете задать альтернативные валидации в конкретном представлении или заменить их (для этого существует поведение, но сделать это не составит труда и без него).
Многомерные массивы немного нелепы, но, скорее всего, у вас все равно будут многомерные объекты. PHP4 имел неверную объектную модель, именно поэтому CakePHP не использует объекты. Это будет исправлено в будущей версии CakePHP (как я уже упоминал выше в комментарии), но все же полезно иметь фреймворк, который поддерживает PHP4 в некоторых случаях. Снова, ваше мнение может отличаться, и я согласен, что полная поддержка PHP5 будет огромным подспорьем как в скорости приложения, так и в разработке.
Вы сможете легко менять базы данных. CakePHP не допускает функциональности, которая присуща только одному типу БД (поэтому была отменена поддержка ENUM, которая есть только в MySQL), так что ORM всегда поддерживается и всегда может строить корректные запросы. Вы можете иметь несколько баз данных в одном приложении, по одной для каждой модели, и можете менять их по своему усмотрению или вообще обойтись без базы данных для конкретной модели. Так что нет, он не привязан к конкретной базе данных.
В конечном итоге ваш выбор остается за вами, и я искренне рекомендую ознакомиться с обоими фреймворками, прочитать документацию, изучить группы, каналы IRC, блоги и форумы, чтобы узнать, какой фреймворк больше всего соответствует вашему стилю разработки. Читатель, будьте осторожны, я разработчик на CakePHP, так что мой ответ может быть несколько предвзятым.
В дополнение к уже существующим ответам, если есть возможность, попробуйте оба фреймворка. Я сам активно использую оба и со временем пришел к предпочтению Symfony.
Тем не менее, я убежден, что это не потому, что один из них лучше другого, а потому, что Symfony лучше соответствует моему стилю мышления. Он ближе к тому, как я пишу код вне фреймворка, что делает его более интуитивным для меня. Я ожидаю, что другим может быть удобнее работать с парадигмой другого фреймворка.
Сказав это, я всё-таки считаю, что объектная модель CakePHP является его слабостью из-за использования массивов вместо объектов. (Это порой вызывает у меня сильную ненависть, когда мне нужно сделать что-то, что в этом фреймворке реализовать трудно...) Они могли бы делать то же самое, но возвращать объекты для представления данных, и я думаю, что большинство проблем, с которыми я сталкиваюсь, исчезло бы – вы могли бы добавлять дополнительный функционал в объекты данных, чтобы реализовать то, что хотите, вместо того чтобы писать функции в существующем классе модели и передавать им массив.
Проблемы с модельным слоем CakePHP действительно могут вызывать затруднения. Например, для реализации простой связи "многие-ко-многим" между объектами Category и Item, а затем извлечения всех Items в определенной категории с заданным свойством, приходится прибегать к сложным операциям.
Ваш SQL-запрос выглядит следующим образом:
SELECT items.* FROM items, categories, item_categories WHERE items.available=1 AND categories.id=1 AND item_categories.category_id = categories.id
К сожалению, сделать это в одном запросе с помощью метода find()
модели в CakePHP невозможно.
Кроме того, в базовом API нет удобного способа добавления одной записи в таблицу item_categories
. Существуют некоторые решения, размещенные в интернете, например, поведение, опубликованное в Bakery (http://bakery.cakephp.org/articles/view/add-delete-habtm-behavior), но такие возможности уже поддерживаются многими другими ORM-фреймворками, такими как Propel, Torque (Java), Hibernate (Java), SQLObject (Python) и SQLAlchemy (Python) "из коробки". Вам придется писать много PHP-кода, чтобы компенсировать отсутствующие функции, или использовать необработанные SQL-запросы. Основная цель фреймворка как раз состоит в том, чтобы минимизировать такие задачи, позволяя вам сосредоточиться на разработке приложения, но в результате CakePHP не предоставляет особых преимуществ.
Существуют и другие проблемы, которые также связаны с модельным слоем, включая проблемы с валидацией форм, работу с громоздкими многомерными массивами и необходимость использования сырого SQL, что связывает ваше приложение с конкретной базой данных.
Лично я бы рекомендовал рассмотреть возможность использования Symfony. Это более крупный фреймворк, который может занять несколько дней для изучения, но это того стоит. Я планировал использовать CakePHP для проекта, но столкнувшись с слишком большим количеством подобных проблем, сменил его на Symfony и с тех пор все идет гладко.
Функции startsWith() и endsWith() в PHP
Как получить расширение файла в PHP?
Как читать большой файл построчно?
ReCaptcha 2.0 с использованием AJAX
Почему нельзя вызывать абстрактные функции из абстрактных классов в PHP?