Juste pour équilibrer ce fil, c'est pourquoi j'aime symfony:
- utilise PHP5
- il gère de très gros sites comme Yahoo! Réponses, délicieuses et Daily Motion .
- bonne documentation. le tutoriel jobeet sur le site Web est génial. vous guide directement à travers toutes les fonctionnalités, et une fois que vous avez terminé, vous avez l'impression de pouvoir tout construire.
- est hautement modulaire ; de nombreux composants symfony fonctionnent seuls.
- vous permet de choisir soit Propulez ou Doctrine comme votre ORM. Doctrine est vraiment super et facile à utiliser.
- vous pouvez définir vos modèles avec YAML ou en PHP, à vous de choisir. Certaines personnes n'aiment pas les fichiers de configuration, et vous pouvez vraiment limiter leur utilisation si vous voulez éviter YAML.
- le symfony cli mis à jour (à partir de 1.2) est génial. Je suis d'accord avec abales, avant cette version c'était un peu bancal, mais maintenant c'est très bien documenté et suit un format prévisible.
- il y a beaucoup, et je veux dire beaucoup de similitudes avec Ruby on Rails, sauf que bien sûr PHP n'est pas aussi joli ou flexible que Ruby (!). Mais si vous parlez à un développeur de gâteaux, il dira probablement le contraire :)
- le générateur d'administrateur symfony , qui est une avancée par rapport à CRUD (qui existe également dans symfony), est un énorme gain de temps. En utilisant votre modèle de données, il générera personnalisable interfaces d'administration complètes avec des vues de liste (index), créer et modifier des pages. Ce n'est pas comme le crud de base où il génère la source et vous allez le modifier ... Vous pouvez en fait définir l'apparence de chaque champ, les champs que vous souhaitez inclure, les actions supplémentaires que vous pouvez effectuer sur chaque objet, etc.
Conceptuellement, je dirais que la différence est la suivante:
- CakePHP a une courbe d'apprentissage plus petite. Si vous n'avez jamais utilisé de framework MVC, Cake sera plus facile à prendre en main et à exécuter en peu de temps.
- Symfony se sent un peu "plus gros", pour ne pas dire qu'il est lent, mais qu'il y a beaucoup de code là-bas qui vous permettra de faire beaucoup de choses vraiment avancées lorsque vous en aurez besoin.
Le meilleur conseil que je puisse donner est d'essayer de configurer rapidement votre propre modèle de données simple dans les deux, et d'expérimenter avec certaines interfaces de base, et de voir simplement ce qui convient le mieux à votre propre style de codage. Je pense que les deux cadres ont des communautés d'utilisateurs très actives et passionnées et vous ne regretterez pas votre décision de toute façon.
- La philosophie de CakePHP est similaire à Ruby on Rails.
- CakePHP est meilleur pour les projets moyens.
- CakePHP est plus rapide à apprendre.
- CakePHP est plus léger que symfony.
- L'interaction avec la base de données de CakePHP utilise CRUD.
- CakePHP utilise le système de test PHPUnit.
- Est intéressant dans CakePHP Bake et échafaudage.
- La philosophie de Symfony est que chaque version est différente.
- Symfony est plus lent à apprendre.
- Symfony est le meilleur pour les grands projets.
- L'interaction avec la base de données de Symfony utilise la doctrine.
- Symfony utilise le système de test PHPUnit.
- Est intéressant dans les bundles et les modèles de Symfony.
Une grande différence réside dans la façon dont les modèles sont créés: les modèles CakePHP sont écrits en PHP et les modèles Symphony sont écrits en YAML et propulsés par Propel. L'approche de CakePHP est plus similaire à ActiveRecord de ROR (bien que ce ne soit pas exactement une implémentation AR). CakePHP, en général, est plus Rails-esque.
La documentation et les outils de CakePHP, à mon avis, ont un public cible plus large et la syntaxe et les assistants sont plus faciles, mais vous n'avez pas encore adopté PHP5 comme cible exclusive (le chargement automatique n'est pas vraiment là). En général, je préfère l'approche de CakePHP parce qu'elle suit en quelque sorte une norme établie, et j'applaudis son organisation. Je recommanderais également Kohana pour sa qualité PHP5.
Il y a n autre post sur le débordement de pile à propos de cette question, bien que son objectif soit un peu différent.
Edit: J'ai revisité Symfony pour trouver les raisons pour lesquelles j'ai dit "non" et je suis venu avec celles-ci - vos opinions et votre kilométrage peuvent varier:
CakePHP propose également des échafaudages simples et des outils CLI faciles à comprendre. La syntaxe CLI de Symphony est un peu bizarre pour moi, et 'CRUD' dans Symfony n'est tout simplement pas le même. Combinez cela avec la syntaxe d'action de Symfony (maladroit) et ajoutez le site Web mal conçu (et difficile à comprendre) de Symfony, et la préférence pour la documentation payante tierce (livres sur Amazon) et vous avez plus de graduations dans la colonne des inconvénients.
Certaines des affirmations sur CakePHP et les limitations ci-dessus ne sont tout simplement pas vraies. La requête est possible. Vous devez juste savoir comment le faire. Le "automagic" de CakePHP est SUPER Nice, vous pouvez donc frapper le sol en cours d'exécution RAPIDE. C'est de loin le cadre le plus RAPIDE à développer (d'où pourquoi il est si étroitement modelé après RoR qui a évidemment été un grand succès et buzz). Il existe des comportements plus avancés pour obtenir des données renvoyées différemment et effectuer certaines de ces requêtes plus complexes avec quelques appels de méthode courts et des paramètres de tableau spécifiés.
Pourtant. Pour autant que je sache, aucun autre framework n'a autant de méthodes et de classes "automagiques". Cake prend les tâches les plus courantes et fournit un moyen facile de le faire. Si vous êtes vraiment intelligent, vous ferez la plupart de votre codage au niveau du modèle et utiliserez les fichiers app_model et app_controller et aurez une application extrêmement efficace.
La console est géniale et toujours en expansion. La communauté est vraiment incroyable et il existe de nombreuses contributions pour vous aider à faire avancer les choses encore plus rapidement. Vous pouvez littéralement architecturer puis déplacer des "pièces" en place pour créer une application très rapidement car la plupart de ce dont vous aurez besoin est disponible. Vous n'obtenez pas cela avec un autre cadre. Vous devez passer BEAUCOUP plus de temps à coder habituellement.
Enfin. Alors que la documentation était à la traîne, c'est beaucoup mieux maintenant et bien que Cake ait également reçu des critiques dures pendant ce manque de documentation et de la période de la version 1.1 ... C'était TOUJOURS bien, juste gravement ignoré. Avec 1.2 et maintenant Cake2 et Cake3 à l'horizon ... Vous allez voir beaucoup d'opinions changer.
J'utilise CakePHP depuis la 1.1. J'y crois fermement. Je l'ai utilisé pour d'énormes sites d'entreprise. Qui reçoivent des millions et des millions de visites par jour ... Nous sommes hors du domaine des choses comme WordPress et Drupal pour les solutions. Quand vous arrivez à ce niveau pour un site de type CMS, je suis super content d'avoir CakePHP dessus. De même, Symfony et CodeIgniter vous aideront avec la mise à l'échelle. Je ne peux rien dire de mal à propos de l'un ou l'autre de ces cadres. Je peux seulement dire passera moins de temps à coder et trouvera une plus grande communauté (et un canal IRC) super sympa avec CakePHP.
Je passe en revue et documente certaines de mes réponses aux commentaires ci-dessus sur CakePHP et certains de ses défauts (dans certains cas à juste titre) perçus.
Les gros sites Web sont gérés à l'aide de CakePHP, certains étant des extensions Mozilla, Scratch by MIT et Hot Scripts. Il y a une liste plus grande juste en bas du site Web de CakePHP ( http://cakephp.org ). Quoi qu'il en soit, tout bon développeur devrait être en mesure de créer un site Web évolutif en utilisant un cadre tant que le cadre n'est pas complètement idiot (CakePHP n'est pas trop idiot: D).
Il est vrai qu'il n'y a pas un très bon tutoriel CakePHP (gratuit) qui passe par toutes les fonctionnalités du framework, mais la documentation est extrêmement bien présentée et détaillée. Tout ce qui n'est pas clair peut être clarifié via le groupe Google et sur IRC, et nous nous félicitons de toutes les modifications/corrections de la documentation. La documentation n'est pas seulement un problème majeur pour les développeurs, car beaucoup de choses sont spécifiques à l'application et les gens proposent des trucs et astuces intéressants, et donc tout le monde est invité à contribuer (pas seulement des commentaires!). Bien sûr, tout est modéré, donc la majeure partie de la cruauté/du spam n'est pas ajoutée.
Le code est modulaire en ce que vous pouvez ajouter du nouveau code qui remplace les fonctionnalités de base. Une grande partie du code est simplement PHP classes. Il est vrai que l'écriture de telles fonctionnalités peut être un fardeau, et je n'ai pas essayé d'utiliser des classes alternatives comme fillins. Oui, il ne gère pas les autres ORM, vous êtes donc coincé avec la valeur par défaut, mais cela devrait être corrigé dans Cake3, qui sera capable de mélanger et de faire correspondre toutes les autres classes PHP à volonté (cela inclut Propel et Doctrine support).
La CLI est très bonne et elle est facile à étendre pour une prise en charge spécifique à l'application. Un exemple est que j'ai récemment développé un plugin Shell qui installerait automatiquement tout autre plugin CakePHP que j'ai indexé à partir de github. Il a fallu environ 5 heures pour construire quelque chose d'extrêmement utilisable et flexible. Je suis sûr que de telles fonctionnalités existent pour Symfony, et elles existent pour RoR :)
Quant à ressembler à Rails, il l'est et ne l'est pas. Beaucoup de choses sont similaires, ce sont des frameworks MVC après tout, et CakePHP opte pour l'approche "Conventions vs Configuration". PHP4 prend en charge mucks avec une syntaxe plus agréable, que Symfony a sans aucun doute en raison de la prise en charge uniquement de PHP5, mais il est toujours extrêmement utilisable et intuitif. Le framework ne fournit pas CHAQUE fonctionnalité de Rails out of the box car ce n'est pas un clone direct. CakePHP est un framework, pas une bibliothèque (salut Zend), donc il ne fournira pas tout hors de la boîte.
La génération de vues est, je suis d'accord, un peu bizarre dans CakePHP. Il est grandement amélioré dans CakePHP 1.3 et 2.0. Il prendra en charge des modèles personnalisés pour chaque modèle, vue et contrôleur (par opposition à un simple type de vue comme il le fait actuellement). En outre, il existe un ensemble de tâches Shell sur github par un utilisateur utilisant neilcrookes qui ne cuit automatiquement que certains types de vues (y compris uniquement les vues d'administration) qui peuvent être utilisées en combinaison avec des modèles personnalisés pour produire exactement ce que vous voulez. Le style CSS aide également :) mais c'est certainement quelque chose qui peut être amélioré.
CakePHP prend de nombreux paramètres variés dans ses méthodes Model :: find, bien que dans certains cas, il puisse être utile d'utiliser des requêtes SQL brutes. La méthode Model :: find () est très flexible et ne m'a pas échoué dans la mesure où elle crée des trouvailles complexes. Je suppose que cela est lié au fait d'être à l'aise avec l'ORM, ce qui prend inévitablement toujours du temps.
La validation du formulaire doit logiquement se trouver dans la couche modèle, car c'est là que toute action liée à la base de données est exécutée. Vous pouvez spécifier une validation alternative dans une vue spécifique, je crois, ou échanger des validations (il y a un comportement pour cela mais il ne serait pas difficile de le faire sans cela).
Les tableaux multidimensionnels sont un peu stupides, mais vous auriez probablement des objets multidimensionnels. PHP4 avait un modèle d'objet cassé et c'est pourquoi CakePHP n'utilise pas d'objets. Ceci est en cours de correction dans une future version de CakePHP (comme je l'ai souligné ci-dessus dans un commentaire précédent), mais il est utile d'avoir un framework qui supporte PHP4 dans certains cas. Encore une fois, YMMV et moi sommes d'accord pour dire que PHP5 complet sera une grande aubaine, à la fois en termes de vitesse d'application et de développement.
Les bases de données peuvent être échangées à volonté. CakePHP n'autorise pas les fonctionnalités inhérentes à un seul type de base de données (d'où la suppression du support des ENUM qui ne sont que dans MySQL), de sorte que l'ORM est toujours pris en charge et peut toujours générer des requêtes valides. Vous pouvez avoir plusieurs bases de données dans une application, une pour chaque modèle si vous le souhaitez, et les échanger à volonté ou même ne pas utiliser du tout de base de données pour un modèle spécifique. Donc non, il n'est pas lié à une base de données spécifique.
En fin de compte, votre choix est le vôtre, et je suggère de tout cœur de les examiner et de lire la documentation, de consulter les groupes, IRC canaux, blogs et tous les forums pour les deux et de voir quel cadre convient le mieux à votre style de développement. Lecteur attention, je suis un développeur CakePHP donc mon article a un certain biais.
En plus des réponses existantes, vous devriez essayer les deux si possible. J'utilise les deux à la fois, et depuis un certain temps, je préfère symfony.
mais je suis assez convaincu que ce n'est pas parce que l'un ou l'autre est meilleur, mais parce que symfony correspond à la façon dont mon esprit fonctionne mieux, c'est plus proche de ce que je fais lorsque j'écris des logiciels en dehors d'un cadre, donc je me sens plus intuitif. Je m'attends à ce que d'autres trouvent que leur esprit correspond au paradigme d'un autre cadre.
Cela dit, je pense que les objets de cakephp sont une faiblesse, à travers l'utilisation de tableaux plutôt que d'objets. (C'est quelque chose qui se développe périodiquement en une haine intense en moi chaque fois que j'ai besoin de faire quelque chose que cela rend difficile ...!) Ils pourraient faire exactement la même chose, mais retourner des objets plutôt que des tableaux pour représenter des données, et je pense que la plupart des les problèmes que j'aurais disparaîtraient - vous seriez en mesure d'ajouter des fonctionnalités supplémentaires dans les objets de données pour réaliser les choses que je veux faire, plutôt que d'écrire des fonctions dans la classe de modèle existante et de leur passer un tableau.
Une différence de plus est: Symfony séparé en 3 environnements: Développement, Production et Test - CakePHP ne peut pas! Il est facile de développer et de tester des produits en même temps
La couche modèle de CakePHP est un gâchis. Essayez de faire des choses simples comme une relation plusieurs-à-plusieurs entre une catégorie et un objet Item, puis récupérez tous les articles d'une catégorie qui ont un jeu de propriétés spécifique.
Comme:
SELECT items.* FROM items, categories, item_categories WHERE item.available=1 AND category.id=1 AND item_categories.category_id = category.id
Quelque chose de si trivial n'est pas possible dans une déclaration dans le gâteau avec la méthode find () d'un modèle.
Il n'y a également aucun moyen dans l'API principale d'ajouter une seule relation plusieurs-à-plusieurs comme dans un élément à la table item_category ci-dessus. Il y a quelques solutions en ligne, y compris un comportement que quelqu'un a publié dans la boulangerie ( http://bakery.cakephp.org/articles/view/add-delete-habtm-behavior ), mais c'est juste des trucs que tout bon cadre ORM comme Propel, Torque (Java), Hibernate (Java), SQLObject (Python), SQLAlchemy (Python) prend en charge dès la sortie de la boîte. Fondamentalement, vous devrez soit écrire beaucoup de code PHP pour ajouter ces fonctionnalités manquantes, soit utiliser des requêtes SQL brutes, mais l'objectif principal d'un framework est d'éviter de faire ces choses pour que vous peut se concentrer sur l'application que vous écrivez donc vous ne gagnez pas vraiment beaucoup avec CakePHP.
Il y a un tas d'autres problèmes et ils ont tous vraiment à voir avec la couche modèle, y compris la validation du formulaire liée à la couche modèle, avoir à gérer des tableaux multidimensionnels désordonnés, avoir à utiliser SQL brut et lier votre application à une base de données spécifique .
Je dirais utiliser symfony. C'est un cadre plus grand qui peut prendre quelques jours de plus à apprendre, mais cela en vaut la peine. J'allais utiliser CakePHP pour un projet sur lequel je travaille, après avoir rencontré trop de ces types de problèmes, je suis passé à symfony et la navigation s'est bien déroulée.
Cake 2.0 charge automatiquement la plupart des classes dont vous avez besoin, alors que j'ai trouvé dans Symfony 2 que chaque classe devait avoir de nombreuses importations en haut du script. Tenter de mémoriser toutes ces importations est presque impossible , vous avez donc toujours besoin d'une référence à portée de main.
par exemple. Code contrôleur Symfony 2 ...
namespace Acme\HelloBundle\Controller;
use Symfony\Component\HttpFoundation\Response;
// bunch of other imports accumulate here...
class HelloController {
...
Argh, beurk. Bien que cela puisse être bon OO pour les puristes, cela allonge le temps de développement (bye bye RAD). Au moins avec Cake je peux coder la plupart des trucs simples rapidement de la mémoire maintenant.