Avantages de l'utilisation Doctrine pour PHP?

Question

Juste est tombé sur le Doctrine projet qui a un objet Relational Mapper et une couche d'abstraction DB. Qu'est-ce que la doctrine dispose que les autres couches d'abstraction PHP ne le font pas? Et quelle pratique peut vous mettre l'ORM, à part aller chercher des objets via des requêtes écrites dans Doctrine Query Language? Le langage de requête vraiment quelque chose que vous voulez développer une application Web entière en? Est-il bien performer?

Dans l'ensemble fait construire une application sur la doctrine rendent plus facile à maintenir et à comprendre? Est-il trop conçu et construit sur une couche d'abstraction raisonnable pour des projets de taille petite taille? (<50 écrans GUI), plutôt que de travailler directement avec MySQL.

Answer 1

  

Qu'est-ce que la doctrine dispose que les autres couches d'abstraction PHP ne le font pas?

1. modèle Met en œuvre DataMapper plutôt ActiveRecord.
2. annotations , XML et YAML pour le schéma.
3. Utilise DQL .
4. Utilise les avantages de PHP 5.3 +.
5. est rapide et a une grande communauté.
6. Sauf ORM il y a ODM.

  

Le langage de requête vraiment quelque chose que vous voulez développer une application Web entière en?

Juste une partie de l'application responsable de la maintenance des objets-entreprises doivent être conscients de l'existence de la doctrine. Et cette partie ne doit pas être 100% par rapport Doctrine.

  

Dans l'ensemble la construction d'une application ne Doctrine sur le rendre plus facile à maintenir et à comprendre?

Certainement. Le code est plus facile à lire, à comprendre et à entretenir.

  

Est-il trop d'ingénierie, et est-il judicieux pour des projets de taille petite taille?

En fait, la doctrine est assez simple dans ses fondamentaux. Et c'est un très bon choix pour les petites, moyennes et même quelques grandes applications.

---

Doctrine n'est pas la réponse à tout et parfois il est un peu problématique. Toutefois, pour les tâches typiques, il est extrêmement utile. À mon humble avis le meilleur ORM / ODM pour PHP en ce moment.

Answer 2

Je voudrais ajouter quelques points à la réponse de Crozin, mais ne peut malheureusement pas commenter. Ici, ils sont:

• Doctrine ne pas utiliser des méthodes magiques __get () et __set () aux attributs de l'entité d'accès, tous les attributs d'entité devraient avoir getter / setter. Cela améliore le code IDE achèvement et vous n'avez pas besoin de regarder la structure de table DB tout le temps.
• Doctrine vous entièrement abstraction de noms de champs de table réelle. Une fois que vous avez mappée propriétés d'entité aux champs DB - vous utilisez des noms de propriété partout. Idem pour les noms de table.
• Doctrine utilise motif référentiel qui cache les détails de l'obtention d'entités.
• Doctrine utilise l'approche « code d'abord », de sorte que vous pouvez créer des entités d'abord, puis générer la base de données pour eux automatiquement. cas inverse est également possible.
• Doctrine a puissant générateur de requêtes, de sorte que vous pouvez utiliser pour les requêtes motif constructeur avec des pièces conditionnelles.
• Doctrine utilise les clés étrangères et les contraintes d'effectuer des actions en cascade et conserver des données cohérentes.
• UnitOfWork de la doctrine est une chose assez grand et intelligent, qui n'a pas d'analogue dans d'autres ORM php

à mon humble avis à la doctrine moment offre le meilleur soutien de la complétion de code IDE et abstraction de la couche DB parmi tous les php ORM disponibles. Il est pas trop conçu et suit des principes solides.

Answer 3

Je voudrais ajouter un point à la réponse de GerKirill. L'absence d'appui magiques getter / méthodes de réglage est une faiblesse, IMHO, et non une force. Si vous avez déjà fait défiler des dizaines de pages de getters / setters identiques, vous vous rendrez compte que ces méthodes sont un énorme gaspillage d'espace (sans parler de compilation). Personne ne fixe accidentellement une variable d'objet, et un setter ne vous empêche de le faire ... quand vous voulez pas changer la propriété, vous appelez simplement le poseur (comment fonctionne un setter « protéger » la propriété - si vous êtes va faire une faute de frappe et mettre directement la mauvaise valeur de la propriété, vous ferez la même faute de frappe et appeler le mauvais compositeur). Et il est très rare pour un poseur ou getter à faire autre chose que obtenir ou de définir une propriété. Si vous devez faire quelque chose de spécial pour définir ou obtenir une propriété, que la propriété doit être une méthode (voir http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html ), ou vous devriez être refactoring votre code, ou vous devriez être appeler une fonction de validation de propriété (généralement au moment où l'objet est créé). Ceci est l'un de ces truismes un-défi qui affligent le monde OO. Pensez-y avant de poster la réponse standard idées reçues.