About the query container

Last updated:
Edit on GitHub
When to use query containers

Don’t use query containers to cross module boundaries, as this increases module coupling. However, you can use them behind Repository and Entity Manager as query aggregations.

Previously, query containers were used to cross-module borders (using dependency providers), which led to higher module coupling and leaking of the Persistence layer from one domain object to another, and therefore, to higher maintenance efforts and lower code reusability. This approach is deprecated, so we don’t recommend using query containers like this in your project development.

A query container holds all the database queries of the current module.

Each module has exactly one query container, which also acts as an entry point to the Persistence layer. Internally, it uses query objects and returns unterminated queries.

As you can see in the following example, the query container consists of query-methods. It gets query objects from the factory, adds some filters or joins, and returns the unterminated query object.

Avoid unterminated queries in the Application layers above Persistence. To decouple persistence and ORM implementation details, consider using the Repository and Entity Manager patterns.

Unterminated means you don’t execute the query with find(), findOne(), or count().

use Spryker\Zed\Kernel\Persistence\AbstractQueryContainer;

/**
 * @method \Pyz\Zed\MyBundle\Persistence\MyBundlePersistenceFactory getFactory()
 */
class MyBundleQueryContainer extends AbstractQueryContainer implements MyBundleQueryContainerInterface
{
    public function queryTemplateByPath($path)
    {
        $query = $this->getFactory()->createTemplateQuery();
        $query->filterByTemplatePath($path);

        return $query;
    }
}

To generate the related code, you can use the following definitions:

  • vendor/bin/console spryk:run AddZedPersistencePropelAbstractQuery: Add Zed Persistence Propel Abstract Query

For details, see Spryks.

Next steps