php – Laravel存储库和雄辩的模型

在阅读了一些教程并主要观看Laracasts上的视频之后,我正在考虑使用Repositories在我的网站中添加一个抽象层,它将通过接口注入我的控制器中.存储库用于抽象模型的检索方式并隐藏一些业务逻辑.使用Laravel中提供的Bind方法,这看起来非常简单方便.

将单元测试添加到项目中听起来非常有趣,但我无法理解应该如何处理模型.

例如,假设我们试图隐藏存储库后面的旧用户模型,方法是创建:

interface UserRepositoryInterface {
    public function getAll();
    // ...
}

然后,支持Laravel提供的标准用户模型,定义如下:

class User extends Eloquent implements UserInterface, RemindableInterface {
    // ...
}

我们创建UserRepositoryInterface的Eloquent实现:

class EloquentUserRepository extends UserRepositoryInterface {
    public function getAll() {
        return User::all();
    }
}

我不明白的部分是,现在,Repository没有返回“通用”模型,它返回一个Eloquent模型!对我来说没有意义的是,其他存储库应该返回相同类型的模型,如果不是这样的话,如果返回的模型之间根本没有相关性,那么拥有存储库有什么意义呢?

那么在Laravel中正确使用Repository模式是什么?

最佳答案 Laravel中的存储库有助于保持控制器的薄弱和愚蠢.

控制器在处理存储库之前处理任何路由或数据解析,并以适当的格式返回数据.

存储库可以处理模型.

如果这两个函数都使用相同的控制器方法,则无法确定问题是从输入中解析数据还是从模型中请求数据.

这种分离允许使用以确保控制器将适当的数据传递到存储库.存储库正在执行适当的验证并以正确的方式访问模型,并且所有这些都返回了正确类型的数据.

可以使用instanceof测试存储库返回的模型的类型:

public function testAllReturnsCollection()
{
    $collection = $this->machineRepository->all();
    $this->assertTrue($collection instanceof \Illuminate\Database\Eloquent\Collection);
}

public function testFindReturnsMachine()
{
    $model = $this->machineRepository->find($this->machineId);
    $this->assertTrue($model instanceof Machine);
}

这种类型的测试也可以使用Mocking完成,但在使用模型时,我更喜欢使用测试数据库.

点赞