¿Cuál es su experiencia con Doctrine ORM?

Question

¿Cuál es su experiencia con doctrine? Nunca he sido un tipo de tipo ORM, la mayoría de las veces solo administré una capa básica de abstracción de db como adodb.

Pero entendí todos los conceptos y beneficios de la misma. Entonces, cuando surgió un proyecto que necesitaba un ORM, pensé en probar uno de los framework ORM.

Tengo que decidir entre la doctrina y la propulsión, así que elijo doctrina porque no quería manejar el requisito de phing.

No sé lo que hice mal. Entré con la mentalidad correcta. Y de ninguna manera soy un niño php 'junior'. Pero he estado luchando contra el sistema en cada paso del camino. Hay mucha documentación pero todo se siente un poco desorganizado. Y cosas simples como la creación de tablas de YAML a db simplemente no funcionarían y simplemente funcionarían sin ningún error ni nada. Una gran cantidad de otras cosas funciona un poco funky requieren solo un poco más de ajuste antes de trabajar.

Tal vez hice una suposición de novato estúpido de aquí que una vez que descubrí lo que es, tendré el momento. Pero ahora estoy totalmente odiando el sistema.

¿Hay alguna sugerencia que alguien pueda darme o tal vez apuntarme a un buen recurso sobre el tema o algún sitio o persona autorizada sobre esto? ¿O tal vez simplemente recomendar otro marco ORM que 'simplemente funciona'?

Answer 1

No soy un experto con Doctrine, simplemente comencé a usarlo y tengo que admitir que es una experiencia un tanto mixta. usted, pero no siempre es inmediatamente obvio cómo decirle que haga esto o lo otro.

Por ejemplo, al tratar de usar archivos YAML con el descubrimiento automático de relaciones, la relación muchos a muchos no se tradujo correctamente en el modelo php definición. No hay errores como usted menciona, porque simplemente no lo trató como muchos a muchos.

Yo diría que probablemente necesite tiempo para entender esta o aquella manera de hacer las cosas y cómo los elementos interactúan juntos. Y tener tiempo para hacer las cosas paso a paso sería algo bueno y tratar los problemas uno a la vez en una especie de aislamiento. Tratar de hacer demasiado a la vez puede ser abrumador y puede hacer que sea más difícil encontrar el lugar donde algo está yendo mal.

Answer 2

Estoy usando Doctrine en un proyecto de tamaño mediano donde tuve que trabajar desde bases de datos preexistentes que no son de mi propiedad. Le da muchas características integradas, pero tengo una gran queja.

Como tuve que generar mis modelos desde las bases de datos y no al revés, mis modelos están demasiado cerca de la base de datos: los campos tienen nombres muy similares a las columnas de la base de datos, para obtener objetos sql esencial (¿dónde pongo ese código, y cómo lo pruebo?), etc.

Al final tuve que escribir un envoltorio complejo para la doctrina que me hace cuestionar si no hubiera sido más fácil solo use el antiguo enfoque dao/modelo y deje la doctrina fuera de la imagen. El jurado aún está deliberando sobre eso. ¡Buena suerte!

Answer 3

hemos estado utilizando Propel con Symfony durante 2 años y Doctrine con Symfony durante más de 1 año. Puedo decir que cambiar a ORM con framework MVC fue el mejor paso que hemos dado. Recomendaría seguir con Doctrine, aunque toma algo de tiempo aprender a trabajar con él. Al final, encontrará que su código es más legible y flexible.

Si está buscando un lugar donde comenzar, le recomiendo el tutorial de Symfony Jobeet http://www.symfony-project.org/jobeet/1_4/Doctrine/en/ (los capítulos 3, 6 cubren los conceptos básicos) y, por supuesto, la documentación de Doctrine.

Como escribí anteriormente, hemos estado usando Doctrine desde hace algún tiempo. Para hacer que nuestro trabajo sea más cómodo, desarrollamos una herramienta llamada ORM Designer (www.orm-designer.com) donde se puede definir el modelo DB en una interfaz gráfica de usuario (no más archivos YAML :-), que no son tan malos en absoluto) Puede encontrar también algunos tutoriales útiles.

Answer 4

Mis experiencias suenan como la tuya. Recién comencé a usar doctrina y nunca he usado Propel. Sin embargo, estoy muy decepcionado con Doctrine. Su documentación es terrible. Mal organizado, y bastante incompleto.

Answer 5

Tengo sentimientos encontrados. Soy un maestro en SQL solo porque es muy fácil de verificar. Puede probar las instrucciones SELECT rápidamente hasta que obtenga los resultados correctos. Y refactorizar es muy fácil.

En Doctorine, o cualquier ORM, hay tantas capas de abstracción que casi parece TOC (obsesivo/compulsivo). En mi último proyecto, en el que probé Doctrine, golpeé varias paredes. Me tomó varios días encontrar una solución para algo que sabía que podría haber escrito en SQL en cuestión de minutos. Eso es muy frustrante.

Estoy siendo gruñón. La comunidad para SQL es ENORME. La comunidad/soporte para Doctrine es minúsculo. Claro que podrías mirar la fuente y tratar de resolverlo ... y esos son los problemas que tardan días en resolverse.

Conclusión: no pruebe Doctrine, o cualquier ORM, sin planear en mucho tiempo para hacer gimnasia por su cuenta.

Answer 6

Propel and Doctrine usa PDO. PDO tiene muchos errores abiertos con Oracle Database. Todos ellos relacionados con los campos CLOB. Tenga esto en cuenta antes de comenzar un nuevo proyecto si está trabajando con Oracle. Los errores están abiertos desde hace años. Doctrine y PDO colapsarán trabajando con Oracle y CLOBs

Answer 7

Después de investigar un poco sobre las diversas bibliotecas ORM para PHP, decidí utilizar PHP ActiveRecord. Mi decisión se redujo a la configuración de poco o nada, la naturaleza liviana de la biblioteca y la falta de generación de código. La doctrina es simplemente demasiado poderosa para lo que necesito; lo que PHP ActiveRecord no hace puedo implementar en mi capa de envoltura. Sugiero tomar un momento y examinar cuáles son sus requisitos en un ORM y ver si un simple como PHP ActiveRecord ofrece lo que necesita o si una implementación de registro activo rodado en el hogar sería mejor.

Answer 8

Creo que mtbikemike lo resume perfectamente: "Me tomó varios días encontrar una solución para algo que sabía que podría haber escrito en SQL en cuestión de minutos". Esa también fue mi experiencia. SAD (Slow Application Development) está garantizado. Sin mencionar el código feo y las limitaciones en cada esquina. Las cosas que deberían tomar minutos llevan días y las cosas que normalmente serían más complicadas y tardarían horas o días simplemente no son factibles (o no valen la pena el tiempo). El código resultante es mucho más detallado y críptico (porque realmente necesitamos otro lenguaje de consulta, DQL, para que las cosas sean aún menos legibles). Hay bichos extraños por todas partes y la mayor parte del tiempo los dedica a buscarlos y a encontrar limitaciones y problemas. Doctrine (solo utilicé v2.x) es similar a un ejercicio inútil y no tiene absolutamente ningún beneficio. Es, con mucho, el componente más odiado de mi sistema actual y realmente el único con grandes problemas. Al entrar en un nuevo sistema, siempre voy y vienen del db a las clases de entidad tratando de averiguar qué nombre es el correcto en diferentes lugares del código. Una pesadilla total.

No veo ningún profesional en Doctrine, solo contras.No sé por qué existe, y todos los días desearía que no lo hiciera (al menos en mis proyectos).

Answer 9

Uso de Doctrine 2.5 en 2015. Parecía ir bien. Hasta que quise usar dos entidades (en un JOIN). [Que es mejor ahora después de que consiguiera una caída de DQL]

bueno:

• de generación de SQL para mí
• uso de claves externas y la integridad referencial
generación
• InnoDB por defecto
• actualizaciones realizadas a SQL con herramienta de línea de comando de doctrina

De acuerdo:

• ser hiper-consciente de la denominación y el mapeo y la forma de nombrar y de cómo asignar entidades a las tablas reales

el malo

• toma mucho tiempo - aprendizaje API costumbre de consulta constructor. O descubriendo cómo hacer un simple ENTRAR, preguntándose si hay mejores técnicas disponibles. Las UNIONES simples parecen requerir la escritura de funciones personalizadas si desea realizar consultas orientadas a objetos.
• [Actualización en la primera impresión más arriba] - Me optó por utilizar DQL, ya que es más similar a SQL

Me parece que la herramienta es grande en el concepto, pero su correcta ejecución desea gran parte del tiempo desarrollador para subir a bordo Estoy tentado de usarlo para la generación de SQL de entidad, pero luego uso PDO para Entrada/Salida real. Solo porque aún no aprendí cómo hacer Foreign Key e Integridad referencial con SQL. Pero aprender eso parece ser una tarea mucho más fácil que aprender complementos de Doctrine incluso con cosas simples como una entidad equivalente a un JOIN.

Doctrina de proyectos existentes

I (estoy empezando a) utilizar Doctrina para desarrollar nuevas funciones en un proyecto existente. Entonces, en lugar de agregar una nueva tabla mysql para la característica, he agregado entidades (que crearon las tablas para mí usando la generación de esquema de Doctrine). Me reservo el uso de Doctrine para las tablas existentes hasta que llegue a conocerlo mejor.

Si tuviera que usarlo en las tablas existentes, yo primero ... limpiar las mesas, lo cual incluye:

• añadiendo la columna ID que es una primaria/clave sustituta
• usando InnoDB/transacción capaz tabla
• mapa de manera apropiada a una entidad
herramienta
• carrera Doctrina de validación (doctrine orm:validate-schema)

Esto es porque Doctrine hace ciertas suposiciones sobre sus tablas. Y porque básicamente vas a manejar tus tablas por código. Por lo tanto, su código y sus tablas deben estar en la mayor cantidad posible de acuerdo 1: 1. Como tal, Doctrine no es adecuado para cualquier tabla de "forma libre" en general.

Pero entonces, es posible que pueda, con cierto cuidado y, en algunos casos, salirse con pequeñas cosas como que no se contabilicen columnas adicionales en sus entidades (no creo que Doctrine revise a menos que se lo pida) Deberá construir sus consultas conociendo con lo que se está saliendo con la suya. es decir, cuando solicita una "entidad" como un todo, Doctrine solicita todos los campos de la entidad específicamente por nombre de columna. Si su esquema actual contiene más nombres de columna, no creo que le importe a Doctrine (no lo hace, como he verificado al crear una columna adicional en mi esquema).

Así que sí, es posible usar Doctrine pero comenzaría pequeño y con cuidado. Lo más probable es que tenga que convertir sus tablas para admitir transacciones y tener el índice sustituto (clave principal), para empezar. Para cosas como Foreign Keys y Referential Integrity, tendrás que trabajar con Doctrine para pulir tus entidades y unirlas perfectamente. Es posible que deba dejar que Doctrine reconstruya su esquema para usar sus propios nombres de índice para que pueda usar FK y RI correctamente. En esencia, cede el control de sus tablas a Doctrine, por lo que creo que debe conocer el esquema a su manera (como poder usar sus propios nombres de índice, etc.).

Answer 10

Uso de Doctrine ORM en 2016 con una experiencia aproximada ~ 2 - 2,5 años.

inherente inconsistencia

SELECT i, p    
FROM \Entity\Item i 
JOIN i.product p 
WHERE ... 

Supongamos entidades son Item y Product. Están conectados a través de Item.product_id a Product.id, y Product contiene Product.model que queremos mostrar junto con Item.

Aquí es la recuperación de la misma "product.model" de la base de datos, utilizando el SQL anterior pero variando los parámetros de SQL:

//SELECT i, p 
$ret[0]->getProduct()->getModel();   

//SELECT i as item, p as product 
$ret[0]['item']->getProduct()->getModel(); 

//SELECT i as item, p.model as model 
$ret[0]['model'];       

punto que estoy haciendo es la siguiente:

estructura de conjunto de resultados de salida se puede cambiar drásticamente dependiendo de cómo se escribe la instrucción DQL/ORM SELECT.

De una matriz de objetos a una matriz de matriz asociativa de objetos, a una matriz de matriz asociativa, según cómo desee SELECT. Imagine que tiene que hacer un cambio en su SQL, luego imagine tener que volver a su código y volver a hacer todo el código asociado con la lectura de los datos del conjunto de resultados. ¡Ay! ¡Ay! ¡Ay! Incluso si se trata de unas pocas líneas de código, depende de la estructura del conjunto de resultados, no existe un estándar común de desacoplamiento completo.

lo que la doctrina es bueno en

En cierto modo, elimina ocupan de SQL, la elaboración y el mantenimiento de sus propias tablas. No es perfecto A veces falla y debe dirigirse a la línea de comando de MySQL y escribir SQL para ajustar las cosas hasta el punto donde Doctrine y usted están contentos, donde Doctrine ve los tipos de columna como válidos y hasta donde está satisfecho con los tipos de columnas. No tiene que definir sus propias claves o índices foráneos, está hecho para usted automáticamente.

lo que la doctrina es malo en

Siempre que necesite traducir cualquier SQL avanzado significativamente a DQL/ORM, puede tener dificultades. Aparte de eso, también puede lidiar con inconsistencias como la anterior.

Consideraciones finales

amo Doctrina para la creación/modificación de tablas para mí y para la conversión de datos de la tabla de objetos, y la persistencia de nuevo, y para el uso de declaraciones preparadas y otros controles y equilibrios, haciendo que mis datos seguros .

Me encanta la sensación de almacenamiento persistente a cargo de Doctrine desde la interfaz orientada a objetos de PHP. Tengo la sensación de que puedo pensar en mis datos como parte de mi código, y ORM se encarga de las cosas sucias de interactuar con la base de datos. La base de datos se parece más a una variable local y he ganado el aprecio de que si cuidas tus datos, te amará de nuevo.

Odio Doctrine por sus inconsistencias y curva de aprendizaje difícil, y tener que buscar sintaxis patentada para DQL cuando sé cómo escribir cosas en SQL. El conocimiento de SQL está disponible, DQL no tiene tantos expertos en la naturaleza, ni un cuerpo acumulado de conocimiento (en comparación con SQL) para ayudarte cuando te quedas atascado.

Answer 11

Por ahora estoy usando Symfony framework con Doctrine ORM, ¿qué hay de usar Doctrine junto con consultas sencillas? Por ej. de knpuniversity, puedo crear método repositorio personalizado como:

 public function countNumberPrintedForCategory(Category $category) 
    { 
     $conn = $this->getEntityManager() 
      ->getConnection(); 
     $sql = ' 
      SELECT SUM(fc.numberPrinted) as fortunesPrinted, AVG(fc.numberPrinted) as fortunesAverage, cat.name 
      FROM fortune_cookie fc 
      INNER JOIN category cat ON cat.id = fc.category_id 
      WHERE fc.category_id = :category 
      '; 
     $stmt = $conn->prepare($sql); 
     $stmt->execute(array('category' => $category->getId())); 
     return $stmt->fetch(); 
... lines 30 - 37 
    } 

estoy sólo tiene que utilizar Entidades Doctrina de ejemplo crear formularios de procesamiento, Cuando necesito una consulta más compleja, hago una declaración simple y tomo los valores que necesito, de este ejemplo también puedo pasar Entidad como variable y tomar valores para hacer una consulta. Creo que esta solución es fácil de entender y toma menos tiempo crear formularios, pasar datos para ellos y escribir consultas complejas, no es tan difícil como escribirlos con Doctrine.