Quel framework dois-je utiliser pour assurer une meilleure mise à jour / facilité de maintenance à long terme, CakePHP ou CodeIgniter?

Question

Je suis en train de choisir un framework à essayer pour PHP. Je l'ai réduit à CakePHP et CodeIgniter. J'ai quelques questions pour ceux d'entre vous qui ont utilisé ou qui sont familiers avec les deux:

1. J'aime le fait que CakePHP conserve la plupart du code en dehors de la racine Web par défaut. Surtout que je risque de finir par utiliser une seule installation de framework pour plusieurs applications. Je vois que CodeIgniter le fera aussi, mais vous devez le configurer et déplacer des éléments. Cette solution de contournement est-elle sécurisée et fiable, ou s'agit-il d'un hack après coup?

2. Lequel (si ce n'est les deux) est plus facile à mettre à niveau et à maintenir sur le long terme? Au fur et à mesure de la sortie des nouvelles versions du framework (et de PHP lui-même). Je ne veux pas que mes affaires cassent ou deviennent obsolètes.

Modifier:

Ceci est un très vieux billet, mais je pensais le mettre à jour avec ce que j'ai finalement fait, à savoir utiliser Kohana.

Answer 1

Vous devez essayer les deux cadres pendant une semaine environ, en construisant quelque chose de trivial (comme un blog ou un wiki) dans les deux domaines, et de voir ce que vous préférez utiliser. Tout ce qui a le plus de sens pour vous vous soutiendra probablement le plus longtemps possible grâce aux mises à niveau et aux déprécations.

CakePHP est dans un état quelque peu volatil, il cherche toujours des bugs lors de la publication de la version 1.2 (qui n’est pas compatible avec les versions antérieures). Je ne suggérerais pas de créer une application critique avec cette application si vous avez besoin de quelque chose de solide pour le moment . Si vous pouvez attendre un mois ou deux que les choses soient réglées, alors c'est probablement un point discutable.

Pour répondre à vos préoccupations:

1) Cake et CI le font de la même manière (iirc). Ils sont également sûrs, fiables et hackers à cet égard.

2) Tout change. Si vous avez besoin d'une assurance concrète et perpétuelle de stabilité et d'une compatibilité ascendante, lancez votre propre cadre. Il n’ya pas grand-chose à faire et vous avez la garantie que rien ne changera à moins que vous ne le vouliez.

Answer 2

J'ai déployé plusieurs applications sur CakePHP et ce fut une très, très belle expérience. Vous ne pouvez pas vous tromper de toute façon, car les deux sont solides.

Answer 3

1. n'est pas un problème.

2. CodeIgniter a un sponsor derrière lui, donc c'est définitivement celui à choisir pour le long terme. En outre, c'est plus rapide.

Answer 4

1. Ceci n'est pas un problème. L'application comporte plusieurs lignes indiquant l'emplacement du code principal et du code de votre application. Il vous suffit de changer ces lignes.

2. Vous ne pouvez jamais anticiper celui-ci.

L'état de PHP est un caractère générique ici. Une application (CI) est conçue pour être compatible avec PHP4, l'autre nécessite PHP5. Si vous devez gérer la possibilité qu'un hôte Web ne prenne en charge que les anciennes versions de PHP, vous devez utiliser CO.

Un autre problème concerne les tests unitaires. Si vous souhaitez que votre infrastructure soit livrée avec des tests, alors CI n'est pas la solution.

Personnellement, je me sens à l'aise avec CI en raison du soutien apporté à l'entreprise. La société derrière CI réalise de réels bénéfices de leurs efforts. Bien que CI soit gratuit, leur produit payant (ExpressionEngine) finira par vivre sur CI. On pourrait en dire autant du Zend Framework et même de la naissance de Rails (initialement conçu pour Basecamp.)

Answer 5

Une correction mineure à un commentaire ci-dessus: les deux sont compatibles avec PHP4, pas seulement CI. De plus, je ne pense pas que le fait d'avoir un sponsor rend CI et plus ou moins évolutif ou maintenable. L’argent ne résout pas le moins du monde ces problèmes.

J'utilise CakePHP pour une variété d'applications et j'en suis satisfait jusqu'à présent. 1.2 est une énorme amélioration par rapport à 1.1, et bien que la source de la bibliothèque puisse passer de RC3 à Final, je ne pense pas que le code que vous écrivez devienne obsolète. Mon seul inconvénient est que le manuel n'est pas aussi complet qu'il devrait l'être (à mon avis), et je me retrouve assez souvent dans l'API. Le compromis, c'est que je comprends maintenant très bien le code en coulisse. En tout cas, je le recommande vivement.

D'un autre côté, je n'ai jamais joué avec CI, je ne peux donc pas recommander CakePHP sur CI. Je prendrais chacun pour un tour et voir lequel vous attrape. Quel que soit votre choix, étudiez à fond ses conventions et ses capacités. Lorsque j'ai commencé avec Cake, j'ai involontairement écrit une série de codes pour faire quelque chose que Cake a fait "automatiquement". en me faisant définir une variable dans le contrôleur.

Answer 6

CodeIgniter est très flexible, comme vous le verrez une fois que vous l’essayez. Donc, comment votre application serait maintenable vous tomberait entre vos mains.

J'ai également déployé plusieurs applications utilisant la même installation. Je crée généralement deux applications pour les projets CMS (une pour l'administrateur et une pour le client).

Answer 7

Pour répondre à vos deux questions du point de vue de CodeIgniter (je n’utilise pas Cake):

1) CodeIgniter ne se maintient pas en dehors de la racine du Web par défaut, mais il peut le faire avec des modifications très simples. La première partie de mon tutoriel sur l'IC series explique comment procéder, ainsi qu’une présentation de la configuration d’une nouvelle instance de CI. Une fois terminé, la seule partie de CI qui doit figurer dans la racine Web est un petit fichier de démarrage index.php.

2) J'ai une application que j'ai développée à l'origine dans CI 1.4.x et j'ai migré avec succès vers 1.5.x puis 1.6.x. À chaque nouvelle version, les développeurs de CI communiquent des instructions de mise à niveau détaillées indiquant ce qui doit être remplacé, de sorte que les mises à niveau sont relativement faciles.

Jim.