2016-03-21 18 views
0

Я пытаюсь использовать этот Symfony сверток: https://github.com/KnpLabs/KnpPaginatorBundleПравильный способ использования класса постраничного в Symfony

В Документах, они используют его контроллер. Таким образом, у них есть легкий доступ к контейнеру обслуживания или к объекту запроса.

Но насколько я понимаю, запрос Doctrine должен быть в репозитории, а не в контроллере, правильно? И у меня уже есть функция, возвращающая записи. Это просто, что служба разбивки на страницы не ожидает «результатов» при создании экземпляра. Он хочет выполнить запрос. Поэтому я не могу вернуть «результаты» контроллеру, но вместо этого в середине этой функции используйте paginator.

С другой стороны, такие вещи, как игра с услугами или запросами, действительно принадлежат контроллерам.

Итак, как это должно быть сделано? Сначала я подумал о том, чтобы вводить службу «knp_paginator» и объект запроса в репозиторий. Но я не думаю, что это правильный путь.

ответ

1

Я бы сказал, что объект Request не должен идти дальше по стеку, чем из контроллера.

Ничто не мешает вам вводить paginator непосредственно в ваш пользовательский репозиторий, так почему бы не сделать это?

your.repository.service.definition: 
    class: Your\Repository\Class 

    # 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"]] 

В хранилище, то вы должны иметь Paginator доступный для использования с QueryBuilder:

public function setPaginator($paginator) 
{ 
    $this->paginator = $paginator; 
} 

... 

$this->paginator->paginate($qb->getQuery(), $page, $limit); 

Для того, чтобы получить ваши $page и $limit переменные в хранилище, вам не нужны Запросить объект. Просто передайте их в качестве параметра при вызове хранилища:

// 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. Вы не хотите создавать объект запроса оттуда из-за неправильного уровня абстракции.

+0

Bu Мне нужен объект Request для получения параметров url ($ request-> query-> getInt ('page', 1)), но я также думал, что мы не должны передавать этот объект где-нибудь ... –

+1

Я отредактировал ответ с дальнейшими разъяснениями – hasumedic

+0

Спасибо @hasumedic! –

1

Предполагая, что у вас есть Custom Repository Class,, у вас может быть метод в этом репозитории, который возвращает запрос или действительный экземпляр Query Builder, а затем вы вызываете этот метод из контроллера и передаете его методу paginate().

+0

Большое спасибо! –

1

Например, где $ дь возвращается пользовательского хранилища (не возвращает результат, но только QueryBuilder его)

$paginator = $this->get('knp_paginator'); 
$pagination = $paginator->paginate(
    $qb->getQuery(), 
    $request->query->getInt($pageParameterName, 1), 
    $perPage, 
    array('pageParameterName' => $pageParameterName) 
); 

 Смежные вопросы

  • Нет связанных вопросов^_^