doctrine2 - inner - doctrina: QueryBuilder vs createQuery?

query builder inner join doctrine 2

Question

En Doctrine puedes crear DQL de 2 maneras:

EntityManager :: createQuery :

$query = $em->createQuery(''SELECT u FROM MyProject/Model/User u WHERE u.id = ?1'');

QueryBuilder :

$qb->add(''select'', ''u'')
   ->add(''from'', ''User u'')
   ->add(''where'', ''u.id = ?1'')
   ->add(''orderBy'', ''u.name ASC'');

Me pregunto cuál es la diferencia y cuál debería usar?

Answer 1

1. DQL es más fácil de leer ya que es muy similar a SQL. Si no necesita cambiar la consulta en función de un conjunto de parámetros, esta es probablemente la mejor opción.

2. Query Builder es una API para construir consultas, por lo que es más fácil si necesita generar una consulta de forma dinámica, como iterar sobre un conjunto de parámetros o filtros. No necesita realizar ninguna operación de cadena para generar su consulta como join, split o lo que sea.

Answer 2

El generador de consultas es solo, digamos, interfaz para crear consultas ... Debería ser más cómodo de usar, no tiene solo el método add (), sino también métodos como where (), andWhere (), from (), etc. Pero al final, solo compone consultas como la que usas en el método createQuery ().

Ejemplo de uso más avanzado del generador de consultas:

$em->createQueryBuilder()
            ->from(''Project/Entities/Item'', ''i'')
            ->select("i, e")
            ->join("i.entity", ''e'')
            ->where("i.lang = :lang AND e.album = :album")
            ->setParameter(''lang'', $lang)
            ->setParameter(''album'', $album);

Answer 3

Ellos tienen diferentes propósitos:

• DQL es más fácil de usar cuando conoces tu consulta completa.
• El generador de consultas es más inteligente cuando tiene que construir su consulta en función de algunas condiciones, bucles, etc.

Answer 4

La principal diferencia es la sobrecarga de llamar a los métodos. Su primer ejemplo de código (createQuery) solo por simplicidad hace una llamada a un método, mientras que el queryBuilder crea 4. Al final de todo, descienden a una cadena que debe ejecutarse, por ejemplo, le está dando la cadena, y el otro lo está construyendo con múltiples llamadas a métodos encadenados.

Si está buscando una razón para usar una sobre otra, esa es una cuestión de estilo, y lo que parece más legible. Para mí, me gusta la queryBuider la mayor parte del tiempo, proporciona secciones bien definidas para la consulta. Además, en el pasado hace que sea más fácil agregar lógica condicional cuando la necesite.

Answer 5

Puede ser más fácil realizar una prueba unitaria al usar el generador de consultas. Digamos que tiene un repositorio que consulta algunos datos basándose en la complicada lista de condiciones. Y desea asegurarse de que si se pasa una condición particular al repositorio, se agregan algunas otras condiciones a la consulta. En el caso de DQL tienes dos opciones:

1) Para usar accesorios y probar la interacción real con DB. Lo cual me parece algo problemático y sin cortes.

2) Para verificar el código DQL generado. Lo cual puede hacer que tu prueba sea demasiado frágil.

Con QueryBuilder, puede sustituirlo con simulacro y verificar que se llame al método "andWhere" con el parámetro necesario. Por supuesto, tales consideraciones no son aplicables si su consulta es simple y no depende de ningún parámetro.