PHP Framework et ORM vs procédures stockées

Question

Je suis en train de choisir un framework PHP pour une application web que je démarre. Je n'ai jamais vraiment utilisé un cadre dans le passé mais avec ce projet il y a un grand besoin.

J'ai débattu entre les suspects habituels; CakePHP, Zend Framework et Symfony. J'ai fait des allers et retours sur le cadre qui fonctionnera le mieux pour moi et ce projet. Je me penche vers CakePHP mais je suis toujours en train de faire des recherches.

Ma question n'est pas quel cadre est le meilleur. Je sais qu'il n'y a pas de véritable réponse à cela et il y a des tonnes de messages liés à ce sujet. Ma question concerne le modèle et l'ORM. J'ai lu beaucoup de choses sur les ORM étant lent et je suis préoccupé par la vitesse. Je suis très à l'aise d'écrire du SQL et dans le passé j'ai essayé de garder toutes mes interactions de base de données dans des procédures stockées.

Je suis à la recherche de commentaires sur l'utilisation de ORM ou de Doctrine de CakePHP avec Zend ou Symfony afin de conserver tout dans les procédures stockées. Je sais que les procédures stockées vont être plus rapides mais que vais-je perdre si je n'utilise pas un ORM? Je comprends qu'un ORM me donnera l'abstraction de base de données mais dans mon esprit cela aide juste les gens qui n'écrivent pas SQL. Je sais aussi que je ne connais pas assez les ORM.

Si quelqu'un peut me donner des commentaires à ce sujet et quel cadre pourrait être le mieux basé sur l'utilisation ou non d'un ORM.

Merci pour toute aide à l'avance.

Answer 1

Les ORM sont pour les programmeurs qui ne "grock" pas SQL! Oui, les ORM facilitent (ou nécessitent au moins moins de lignes de code) pour écrire des choses CRUD simples, mais quand on en arrive à des exigences plus complexes, c'est comme essayer d'écrire du SQL avec un spaghetti humide à trois mètres.

Alors restez avec SQL. Cela vaut la peine de regarder quelque chose comme "SQLMap" qui est ORM à partir du côté "R" de la cartographie (la plupart tentent de mapper un "O" bject sur une table). Cela vous permettra d'écrire vous-même le code SQL et de générer les classes "helper" appropriées pour accéder facilement aux résultats de votre programme.

Answer 2

0) Bang pour l'effort

Le principal avantage d'un ORM est que vous ne passez pas beaucoup de temps face à la couche de persistance. Un ORM pré-écrit (j'ai travaillé avec EclipseLink) fournira une tonne de choses que vous n'obtiendrez probablement pas dans les procédures stockées écrites personnalisées. Je pense qu'il vaut la peine de penser au temps que vous voulez passer à écrire votre couche de persistance.

1) Mise en cache

Tous les ORM principaux fournissent des caches distribués à plusieurs niveaux. Combiné avec les requêtes Named/Predefined, vous pouvez obtenir des requêtes SQL qui ne doivent pas nécessairement aller à la base de données. Cela peut vous donner d'excellentes performances.

2) Abstraction

ORM vous permettent de définir votre mise en page de la table dans un endroit, puis ils gèrent tout le mappage entre les colonnes douloureuses/tables et objets. Certains vous permettront de remapper les noms de colonnes, de tables et de schémas sans changer de code du tout. Si vous travaillez avec des gens qui aiment changer les choses, cela peut vraiment simplifier les choses.

3) Vitesse

Certains ORM peuvent avoir de mauvaises performances, mais il est vraiment basé sur la façon dont vous l'utilisez. Je trouve que vous avez tendance à sur-interroger les choses. D'un autre côté, vous obtenez des choses comme les profileurs de requêtes intégrés. Vous pouvez écrire du code SQL personnalisé pour les requêtes si vous constatez que vous n'obtenez pas les performances dont vous avez besoin.

Answer 3

Un cadre met en œuvre principalement trois types de fonctions:

1. le flux entre « obtenir une demande » et « rendre une page ». C'est à vous de mettre des choses comme MVC, routeur, etc ...
2. la façon de gérer votre modèle et sa persistance. C'est là que vous voyez des acronymes comme ORM, DBAL, DAO
3. Composants. Caractéristiques, travaillant souvent aussi autonome. Comme l'analyse Xml, la gestion i18n, la génération pdf ...

Lorsque vous choisissez votre framework, cela signifie en fait que vous choisissez 1). C'est la chose que vous devrez certainement suivre, c'est le flux de votre application. 2) et 3)? Vous pouvez intégrer ceux que vous préférez. Par exemple, je suis sur Zend Framework avec la plupart de ses composants, mais j'utilise Doctrine ORM 2 et l'injection de dépendance de Symfony. Un de mes amis est sur Symfony 2, il utilise aussi Doctrine ORM, mais c'est la génération de pdf et la gestion du courrier avec les composants associés de Zend.

L'autre chose que vous devez savoir s'il existe actuellement une «deuxième génération» de frameworks php/orm, (re) écrit pour tirer parti des nouvelles fonctionnalités de php 5.3, et/ou pour résoudre la performance générale/coupling questions qu'ils (presque) tous avaient. Certains d'entre eux sont prêts pour la production, certains sont encore en cours de développement:

• ORM Doctrine 2 (prêt pour la production)
• Symfony 2 (prêt pour la production)
• CakePhp 2 (actuellement en RC 2, mais le temps votre projet est prêt, il devrait être stable)
• Zend Framework 2 (encore en cours de développement, mais normalement pas si longtemps)
• FLOW 3 (beta2, devrait être prêt bientôt trop)

Pour la partie ORM, je recommanderai d'en utiliser un, en particulier Doctrine. @Mark et @ iainp999 ont expliqué parfaitement pourquoi. Mark Robinson donne une bonne réponse.

Answer 4

Je vais juste sauvegarder ce qu'il dit en donnant notre expérience avec Doctrine2. J'ai choisi d'utiliser Doctrine2 comme ORM avec Zend Framework il y a quelques temps. Notre projet est encore en développement, mais choisir D2 a été une décision que nous n'avons pas regretté un peu. Alors que vous avez encore besoin de beaucoup réfléchir à votre architecture de données, D2 vous donne la possibilité de pouvoir modifier ce modèle à une date ultérieure, le cas échéant. Cela nous a permis d'essayer les choses rapidement dans les premières étapes et la salle de se développer et de changer plus tard quand nous avons décidé que les choses n'étaient pas tout à fait raison - ça arrive. Par rapport au point de Mark sur l'abstraction. L'une des autres choses que j'aime à propos de D2 est que nous travaillons avec des objets PHP anciens. Ne sous-estimez pas le pouvoir d'être capable de penser en termes d'objets - à la fois pour les personnes responsables de la modélisation des données et les développeurs qui travaillent avec les données - cela va vous rendre la vie plus facile, faites-moi confiance.De plus, avoir une documentation en ligne sur le mapping ORM (si vous choisissez l'approche docblock) est sympa.

Droit, performance. Comme le dit Mark, il existe des moyens d'accélérer les choses, mais il y aura toujours des frais généraux. Chaque fois que vous introduisez une autre couche logicielle, il y aura une baisse de performance, mais c'est un compromis. Pour nous, le compromis - les avantages de l'utilisation de l'ORM par rapport à la performance - en vaut la peine. Nous passerions plus de temps à déboguer le code et à ne rien faire sans l'ORM. De toute façon, D2 peut vous aider avec la mise en cache pour les requêtes, les résultats et les métadonnées. Tandis que vous voulez probablement juste un cache de tableau pendant le développement, c'est génial que la facilité pour des choses comme APC, memcache etc. est là quand vous allez tester et déployer. Vous pourriez même développer le vôtre si vous êtes courageux.

http://www.doctrine-project.org/docs/orm/2.0/en/reference/caching.html

espoir qui aide, je l'ai probablement manqué des choses, mais si vous avez des questions simplement les tirer et je ferai de mon mieux.