Ventajas de usar Doctrine para PHP?

Question

Acabo de encontrar el proyecto Doctrine que tiene un asignador relacional de objetos y una capa de abstracción de base de datos. ¿Qué proporciona Doctrine que otras capas de abstracción de PHP no ofrecen? ¿Y para qué uso práctico puede colocar el ORM, además de buscar objetos a través de consultas escritas en Doctrine Query Language? ¿Es el lenguaje de consulta realmente algo en lo que desea desarrollar una aplicación web completa? ¿Funciona bien?

En general, ¿la creación de una aplicación en Doctrine hace que sea más fácil de mantener y comprender? ¿Está sobre ingeniería, y se basa en una capa de abstracción sensible para proyectos de tamaño pequeño-mediano? (< 50 pantallas GUI), en lugar de trabajar directamente con MySQL.

Answer 1

¿Qué proporciona Doctrine que otras capas de abstracción de PHP no tienen?

1. Implementa patrón DataMapper en lugar de ActiveRecord.
2. Admite annotations, XML y YAML para el esquema.
3. Usos DQL.
4. Utiliza los beneficios de PHP 5.3+.
5. Es rápido y tiene una gran comunidad.
6. Excepto ORM hay ODM.

¿El lenguaje de consulta es realmente algo en lo que desea desarrollar una aplicación web completa?

Solo una parte de la aplicación responsable del mantenimiento de los objetos comerciales debe tener en cuenta la existencia de Doctrine. Y esa parte no tiene que ser 100% basada en Doctrina.

En general, ¿la construcción de una aplicación en Doctrine hace que sea más fácil de mantener y comprender?

Definitivamente. El código es más fácil de leer, comprender y mantener.

¿Está sobre-diseñado, y es sensible para proyectos de tamaño pequeño-mediano?

En realidad Doctrine es bastante simple en sus fundamentos. Y es una muy buena opción para aplicaciones pequeñas, medianas e incluso grandes.

---

La doctrina no es la respuesta para todo y, a veces es un poco problemático. Sin embargo, para tareas típicas es extremadamente útil. En mi humilde opinión, el mejor ORM/ODM para PHP en este momento.

Answer 2

Me gustaría agregar algunos puntos a la respuesta de Crozin, pero desafortunadamente no puedo comentarlo. Aquí están:

• Doctrine no utiliza los métodos mágicos __get() y __set() para acceder a los atributos de la entidad, todos los atributos de la entidad deben tener getter/setter. Esto mejora la finalización del código IDE y no necesita mirar la estructura de la tabla DB todo el tiempo.
• Doctrine lo abstrae completamente de los nombres de los campos de tabla reales. Una vez que asignó las propiedades de la entidad a los campos DB, utiliza nombres de propiedad en todas partes. Lo mismo para los nombres de tabla.
• Doctrine utiliza un patrón de repositorio que oculta los detalles de la obtención de entidades.
• Doctrine utiliza el enfoque de "codificar primero", por lo que puede crear entidades primero y luego generar la base de datos automáticamente. El caso inverso también es posible.
• Doctrine tiene un potente generador de consultas, por lo que puede utilizar el patrón de generador para consultas con partes condicionales.
• Doctrine utiliza claves y restricciones foráneas para realizar acciones en cascada y mantener la coherencia de los datos.
• UnitOfWork de doctrina es una bastante grande e inteligente cosa, que no tiene analogía en otros ORM php

mi humilde opinión de la doctrina momento ofrece mejor soporte finalización de código IDE y capa de abstracción de base de datos entre todos los ORM PHP disponibles. No está sobrediseñado y sigue los principios SÓLIDOS.

Answer 3

Me gustaría agregar un punto a la respuesta de GerKirill. La ausencia de soporte para los métodos getter/setter mágicos es una debilidad, en mi humilde opinión, no es una fortaleza. Si alguna vez ha recorrido docenas de páginas de getters/setters idénticos, se dará cuenta de que estos métodos son una gran pérdida de espacio (sin mencionar el tiempo de compilación). Nadie accidentalmente establece una variable de objeto, y un colocador no le impide hacer eso ... cuando quiere cambiar la propiedad, simplemente llama al colocador (¿cómo un colocador "protege" la propiedad? va a hacer un error tipográfico y establecer directamente el valor de la propiedad incorrecta, hará el mismo error tipográfico y llamará al instalador equivocado). Y es muy raro que un setter o getter haga otra cosa que no sea obtener o establecer una propiedad. Si tiene que hacer algo especial para establecer u obtener una propiedad, dicha propiedad debe ser un método (vea http://www.yegor256.com/2014/09/16/getters-and-setters-are-evil.html), o debería estar refactorizando su código, o debería llamar a una función de validación de propiedad (generalmente en el momento en que el objeto está creado). Esta es una de esas perogrulladas sin desafíos que plagan el mundo OO. Piénselo antes de publicar la respuesta estándar de sabiduría recibida.