Я работаю над достаточно крупным проектом Laravel и использую репозитории.
У меня есть пользовательский репозиторий, который вводит свои зависимости так:
public function __construct(CartRepository $cartRepo...) Это вызывает следующую ошибку:
Maximum function nesting level of '100' reached, aborting!
Я думаю, это связано с тем, что CartRepo вводит ItemRepo, который, в свою очередь, вводит UserRepo, вызывая бесконечный цикл вложенности.
То, что я не получаю, так это то, как найти это, ItemRepo нуждается в UserRepo, поскольку элементы привязаны к пользователю?
Кто-нибудь сталкивался с этим раньше? Если да, то как вы обошли это?
Я знаю, что могу увеличить xdebug.max_nesting_level но даже при значении 750 он все еще бросает ошибку, я бы также исправил основную проблему, чем просто ее похоронить.
У вас есть цикл в вашем графике зависимостей:
UserRepo -> CartRepo -> ItemRepo -> UserRepo -> …
Вы не можете это разрешить. Это бесконечный цикл, xdebug.max_nesting_level вам не поможет.
Я просто удивлен тем, что контейнер Laravel DI не бросает явного исключения.
Вы должны переосмыслить свои зависимости между службами / репозиториями, возможно, разбив некоторые классы на более мелкие, менее связанные объекты.
Обновление : Woops, я забыл о нескольких решениях!
Вместо того, чтобы вводить зависимость в конструкторе, вы можете ввести его в сеттер, который будет вызываться после создания объекта. В псевдокоде это будет выглядеть так:
$userRepo = new UserRepository(); $cartRepo = new CartRepository($userRepo); $userRepo->setCartRepo($userRepo);
Я не знаю, поддерживает ли Laravel ленивую инъекцию, но это также решение: контейнер будет вводить прокси-объект вместо фактической зависимости. Этот прокси-объект будет загружать зависимость только тогда, когда к ней обращаются, тем самым устраняя необходимость создания зависимости при вызове конструктора.
Для тех, кто достигает этого ответа и все еще немного не уверен, что делать, как я, я просто хотел поделиться своим решением. Решение Маттие верно, но для начинающего, как и я, он все же не дал мне конкретного ответа на фактическое решение циклической зависимости. В конце концов я пришел к выводу, что мои классы были слишком большими и что их разбить на более мелкие классы, даже классы с помощью одного метода были ответом. Например, если у вас есть класс User, который содержит метод входа и метод регистрации, а затем некоторый другой класс, скажем, Social Class, который использует метод входа в систему пользовательского класса и по какой-либо причине пользовательский класс имеет зависимость от социального класса то моим решением было бы переместить метод входа в свой класс, который не имел бы никаких зависимостей. Таким образом, класс Social теперь использует класс Login, который не имеет никаких зависимостей. В целом я пошел от 3 классов до 9, и это полностью решило проблему для меня. Я думаю, что этот тип мышления интуитивно понятен для новичков, но если вы не знаете, чего не знаете, это может быть жестким.
Причиной вашей ошибки может быть ошибка в Laravel, но в настоящее время я работаю с symfony2, и symfony2 сделал то же самое (на сущности класса, например) без проблем. Каким бы ни был установлен параметр php.ini max_nesting_level (по умолчанию 64), или если вы используете xdebug.max_nesting_level установите xdebug.max_nesting_level . Сначала попробуйте последнее предложение …