在阅读了一些教程并主要观看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完成,但在使用模型时,我更喜欢使用测试数据库.