Question

如果使用这3种类型的用法，类耦合有什么不同：

案例1

use UserRepository

...

UserRepository::getUser();

案例2

App::make('UserRepository')->getUser();

案例3

public function __construct(UserRepository $userRepository)
{
    $this->userRepository = $userRepository;
}
...
$this->userRepository->getUser();

有没有理由更喜欢一个而不是另一个？

修改

我觉得构造函数选项是最好的方法，但是当我需要在控制器中包含3个服务和3个存储库时，我发现自己有问题，然后很快就会升级到构造函数中的6个参数。

编辑 - 案例4

当你使用立面时呢？

编辑 - 案例5

当您将其指定为\UserRepository时会怎样？

Answer 1

首先，Repository的想法是拥有一个Interface（UserRepositoryInterface）和实现它的类（MySQLUserRepository，RedisUserRepository）。它通过调用界面为您提供了一种通过DI容器更改用户存储的快速方法：

public function __construct(UserRepositoryInterface $userRepository)
{
    $this->userRepository = $userRepository;
}

将其更改为DI容器中的任何实现。

假设你有一个包含10个动作的控制器。

案例1 不是OOP方式，因为调用根本没有通过DI容器。

案例2 实际上是正常的，但您必须在每个操作中调用应用程序外观。它不是很漂亮。

案例3 只为您提供了一个创建/更改/配置课程的地方。

E.g。你需要做类似的事情：

public function __construct(UserRepository $userRepository)
{
    $this->userRepository = $userRepository;
    $this->userRepository->excludeAdmins();
}

构造函数中的许多存储库实际上都可以，但是如果代码对您来说很粗略，则可以将其提取到Service类。

<强>更新 By Service类我指的是一个不扩展任何东西并包含业务逻辑的类。

进一步阅读：https://m.dotdev.co/design-pattern-service-layer-with-laravel-5-740ff0a7b65f

案例4 。在我看来，外墙适合更全球化的东西。为什么要用外观填充每个存储库？太耗时了。

案例5 。没有得到问题。你的意思是把它放到根名称空间？它有什么变化？

Laravel DI耦合差异

1 个答案: