3

我正在开发一个相当大的 Laravel 项目，并且正在使用存储库。

我有一个用户存储库，它像这样注入它的依赖项：

public function __construct(CartRepository $cartRepo...)

这会导致以下错误：

Maximum function nesting level of '100' reached, aborting!

我认为这是因为 CartRepo 注入了一个 ItemRepo，而 ItemRepo 又注入了 UserRepo，从而导致了无限嵌套循环。

我不明白如何解决这个问题，ItemRepo 需要 UserRepo，因为项目与用户相关联？

有没有人遇到过这个？如果是这样，你是如何绕过它的？

我知道我可以增加xdebug.max_nesting_level，但即使值为 750，它仍然会引发错误，我也宁愿修复潜在的问题，而不是埋葬它。

4

3 回答 3

5

您的依赖图中有一个循环：

UserRepo -> CartRepo -> ItemRepo -> UserRepo -> …

你无法解决这个问题。这是一个无限循环，xdebug.max_nesting_level不会帮助你。

我很惊讶 Laravel DI 容器没有抛出显式异常。

您必须重新考虑服务/存储库之间的依赖关系，可能通过将一些类拆分为更小、耦合更少的对象。

更新：糟糕，我忘记了几个解决方案！

  • 二传手注入

与其在构造函​​数中注入依赖项，不如将其注入到 setter 中，该 setter 将在构造对象后调用。在伪代码中，它看起来像这样：

$userRepo = new UserRepository();
$cartRepo = new CartRepository($userRepo);
$userRepo->setCartRepo($userRepo);
  • 惰性注入

我不知道 Laravel 是否支持惰性注入，但这也是一种解决方案：容器将注入一个代理对象而不是实际的依赖项。该代理对象仅在访问时才加载依赖项，因此无需在调用构造函数时构建依赖项。

于 2013-11-11T21:49:22.930 回答
0

对于那些得到这个答案但仍然有点不确定该怎么做的人，我只想分享我的解决方案。Matthieu 的解决方案是正确的，但对于像我这样的初学者来说，它仍然没有给我一个具体的答案来实际解决周期性依赖问题。最后我得出的结论是，我的类太大了，把它们分成更小的类，即使只有一种方法的类也是答案。例如，如果您有一个包含登录方法和注册方法的用户类，然后是其他一些类，例如使用用户类的登录方法的社交类，并且无论出于何种原因，用户类都依赖于社交类那么我的解决方案是将登录方法移动到它自己的没有任何依赖关系的类中。这样，Social 类现在使用没有任何依赖关系的 Login 类。总的来说，我从大约 3 节课增加到 9 节课，这完全解决了我的问题。我认为这种类型的思维对于非初学者来说是直观的，但如果你不知道你不知道什么，那就很难了。

于 2015-10-20T19:35:20.690 回答
-2

您的错误的原因可能是 Laravel 上的错误，但我目前正在使用 symfony2，并且 symfony2 做了同样的事情（例如在实体类上）没有问题。无论将您的 php.ini 设置 max_nesting_level （默认为 64）设置为更高的值，或者如果您正在使用 xdebug 检查xdebug.max_nesting_level设置。先试试最后一个建议...

于 2013-11-11T14:56:29.737 回答