我正在尝试使用这个Symfony捆绑包:https://github.com/KnpLabs/KnpPaginatorBundle
在文档中,他们将其用作控制器。因此,他们可以轻松访问服务容器或请求对象。
但据我了解,Doctrine 查询应该在存储库中,而不是控制器中,对吧?而且我已经有一个返回记录的函数。只是分页服务在实例化时不期望"结果"。它需要查询。所以我不能将"结果"返回给控制器,而是在这个函数的中间使用分页器。
另一方面,诸如玩弄服务或请求之类的东西确实属于控制器。
那么应该如何做到这一点呢?起初,我想将"knp_paginator"服务和请求对象注入存储库。但我不认为这是正确的方式。
我想说的是,请求对象不应该比控制器更深入堆栈。
没有什么能阻止您将分页器直接注入您的自定义存储库,那么为什么不这样做呢?
your.repository.service.definition:
class: YourRepositoryClass
# for symfony 2.3
factory_service: doctrine
factory_method: getRepository
# for symfony 2.8 and higher
factory: ["@doctrine.orm.entity_manager", getRepository]
arguments:
- YourBundle:YourEntity
calls:
- [setPaginator, ["@knp_paginator"]]
在存储库中,您应该有分页器可用于 QueryBuilder:
public function setPaginator($paginator)
{
$this->paginator = $paginator;
}
...
$this->paginator->paginate($qb->getQuery(), $page, $limit);
为了将$page
和$limit
变量放入存储库,您不需要 Request 对象。只需将它们作为参数传递给存储库调用:
// In your controller
// You can use forms here if you want, but for brevity:
$criteria = $request->get('criteria');
$page = $request->get('page');
$limit = $request->get('limit');
$paginatedResults = $myCustomRepository->fetchPaginatedData($criteria, $page, $limit);
将请求对象进一步向下传递到控制器意味着您的抽象存在泄漏。应用程序无需担心了解 Request 对象。实际上,请求很可能来自其他来源,例如 CLI 命令。您不希望由于错误的抽象级别而从那里创建 Request 对象。
假设您有一个自定义存储库类,则可以在该存储库中有一个方法,该方法返回查询或查询生成器的有效实例,然后从控制器调用该方法并将其传递给paginate()
方法。
自定义存储库返回$qb(不返回结果,而只是它的查询构建器)
$paginator = $this->get('knp_paginator');
$pagination = $paginator->paginate(
$qb->getQuery(),
$request->query->getInt($pageParameterName, 1),
$perPage,
array('pageParameterName' => $pageParameterName)
);