blocks|key|312829|text|type|unstyled|depth|inlineStyleRanges|entityRanges|data|312830|DQL更易于阅读，因为它与SQL非常相似。如果您不需要根据一组参数更改查询，这可能是最好的选择。|ordered-list-item|312831|查询生成器是一个构造查询的应用程序接口，因此，如果您需要动态构建查询，如迭代一组参数或过滤器，则更容易。您不需要执行任何字符串操作来构建查询，如join、split或其他任何操作。|312832|312833|entityMap^0|0|0|0|0^^$0|@$1|2|3|-4|4|5|6|I|7|@]|8|@]|9|$]]|$1|A|3|B|4|C|6|J|7|@]|8|@]|9|$]]|$1|D|3|E|4|C|6|K|7|@]|8|@]|9|$]]|$1|F|3|-4|4|5|6|L|7|@]|8|@]|9|$]]|$1|G|3|-4|4|5|6|M|7|@]|8|@]|9|$]]]|H|$]]

<ol>
<li>DQL is easier to read as it is very similar to SQL. If you don't need to change the query depending on a set of parameters this is probably the best choice.</li>
<li>Query Builder is an api to construct queries, so it's easier if you need to build a query dynamically like iterating over a set of parameters or filters. You don't need to do any string operations to build your query like join, split or whatever.</li>
</ol>

blocks|key|3048581|text|可以说，查询构建器只是创建查询的接口……它应该更易于使用，它不仅有add()方法，还有where()、andWhere()、from()等方法，但最终，它只是组成了您在createQuery()方法中使用的查询。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3048582|查询构建器的更高级用法示例：|3048583|$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);|code-block|syntax|javascript|3048584|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|L|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|M|8|@]|9|@]|A|$G|H]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

Query builder is just, lets say, interface to create query... It should be more comfortable to use, it does not have just add() method, but also methods like where(), andWhere(), from(), etc. But in the end, it just composes query like the one you use in the createQuery() method.

Example of more advanced use of query builder:

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

blocks|key|3262267|text|它们有不同的目的：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3262268|当您知道完整的查询时，|3262269|DQL更易于使用。当您必须基于某些条件、循环等构建查询时，|unordered-list-item|3262270|查询构建器更智能。|3262271|3262272|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|F|7|N|8|@]|9|@]|A|$]]|$1|G|3|H|5|F|7|O|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

They have different purposes:

<ul>
<li>DQL is easier to use when you know your full query.</li>
<li>Query builder is smarter when you have to build your query based on some conditions, loops etc.</li>
</ul>

blocks|key|312903|text|主要区别在于调用这些方法的开销。为了简单起见，您的第一个代码示例(createQuery)只执行一个方法调用，而queryBuilder执行4个方法调用。最后，它们都归结为一个必须执行的字符串，第一个示例是为其提供字符串，另一个示例是使用多个链式方法调用来构建它。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|312904|如果你想找一个理由去使用它们，这是一个风格的问题，也是一个看起来更易读的问题。对我来说，我最喜欢queryBuider，它为查询提供了定义良好的部分。此外，在过去，当你需要的时候，它可以更容易地添加条件逻辑。|312905|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

The main difference is the overhead of calling the methods. Your first code sample (createQuery) just for simplicity makes one method call, while the the queryBuilder makes 4. At the end of everything, they come down to a string that has to be executed, first example you are giving it the string, and the other you are building it with multiple chained method calls.

If you are looking for a reason to use one over the other, that is a question of style, and what looks more readable. For me, I like the queryBuider most of the time, it provides well defined sections for the query. Also, in the past it makes it easier to add in conditional logic when you need it.

blocks|key|307857|text|使用查询构建器时，单元测试可能更容易。假设您有一个存储库，它根据复杂的条件列表查询一些数据。并且您希望确保，如果将特定条件传递到存储库，则会将其他一些条件添加到查询中。对于DQL，您有两个选择：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|307858|1)使用fixture并测试与DB的真实交互。我觉得这有点麻烦和不统一。|307859|2)检查生成的DQL代码。这可能会使您的测试过于脆弱。|307860|使用QueryBuilder，您可以将其替换为mock，并验证是否调用了带有所需参数的"andWhere“方法。当然，如果您的查询很简单并且不依赖于任何参数，那么这些注意事项就不适用了。|307861|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|J|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|K|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|L|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|M|8|@]|9|@]|A|$]]|$1|H|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|I|$]]

It might be easier to unit test when using the query builder. Let's say you have a repository that queries for some data basing on the complicated list of conditions. And you want to assure that if a particular condition is passed into the repository, some other conditions are added into the query. In case of DQL you have two options: 

1) To use fixtures and test the real interaction with DB. Which I find somewhat troublesome and ununitestish.

2) To check the generated DQL code. Which can make your test too fragile.

With QueryBuilder, you can substitute it with mock and verify that "andWhere" method with needed parameter is called. Of course such considerations are not applicable if your query is simple and not depended on any parameters.

In Doctrine you can create DQL in 2 ways:

EntityManager::createQuery:

<pre><code>$query = $em-&gt;createQuery('SELECT u FROM MyProject\Model\User u WHERE u.id = ?1');
</code></pre>

QueryBuilder:

<pre><code>$qb-&gt;add('select', 'u')
 -&gt;add('from', 'User u')
 -&gt;add('where', 'u.id = ?1')
 -&gt;add('orderBy', 'u.name ASC');
</code></pre>

I wonder what the difference is and which should I use?

doctrine: QueryBuilder vs createQuery?

单元测试

在Doctrine中，您可以通过两种方式创建DQL：EntityManager::createQuery$query = $em->createQuery('SELECT u FROM MyProject\Model\User u WHERE u.id = ?1');QueryBuilder$qb->add('sele...

问信条: QueryBuilder vs createQuery？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问信条: QueryBuilder vs createQuery？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问信条: QueryBuilder vs createQuery？
EN