laravel中的存储库模式的优点是在控制器构造函数中实例化模型

Question

让我们举两个例子。

示例1 （ 存储库模式 ）

接口

interface FooInterface {
    public function all();
}

模型 （在松散的术语中使用它）

class FooModel implements FooInterface {
    public function all()
    {
        return DB::('sometable')->get();
    }
}

服务提供者

  class FooServiceProvider extends ServiceProvider {

      public function register()
      {
        $this->app->bind(
          'Foo\FooInterface',
          'Foo\FooModel'
      );
   }

配置/ app.php

'providers' => array(
  // --
  'Foo\FooServiceProvider'
),

最后 控制器 ：

use Foo\FooInterface as Model;

public function __construct(Model $model)
{
  $this->model = $model;
}

现在我可以像$this->model->all()一样访问这些方法。 那很棒！ 让我们看看第二个例子。

例2 ：

控制器 ：

public function __construct()
{
    $this->model = new \Foo\FooModel();
}

现在我也可以访问与$this->model->all();相同的方法$this->model->all();

题

正如我读到的，使用存储库模式的优势在未来是易于配置/可更改的接口系统。 例如

如果我更改数据库系统，我只需要更改服务提供程序中的绑定 。

但是 ，我也可以轻松地改变控制器构造中的模型实现以实现相同的目的。 比如，将$this->model = new \\Foo\\FooModel()更改$this->model = new \\Bar\\BarModel(); 其中BarModel将保存不同系统的方法。

在存储库模式的优势方面，我到底缺少了什么？ 或者在这种特殊情况下，存储库模式还没有提供太多优势，在某些其他情况下它可能会？ 如果那是肯定的，那可能是什么情况呢？

ps术语模型仅用于Convenince。

Answer 1

这实际上取决于您如何设置代码。 在您的特定情况下，似乎没有太大的好处。

但是，如果您的代码要求您在多个不同的控制器上进行多个模型实例化，该怎么办？ 例如，您可能拥有用户存储库的模型。 可能有许多控制器需要获取有关用户的信息。

然后，通过所有控制器更改所有引用（即您的示例2）将是一件麻烦事。 只更改一次存储库（即您的示例1）要好得多。

编码中从来没有一种尺寸适合所有。 您可以做的最好的事情是为您现在需要的代码编写代码，并了解任何可能有助于未来灵活性的潜在解决方案。 我的观点是存储库模式是有助于灵活性的解决方案之一。 您可能永远不需要更改模型或移动到其他数据库，但与您想要更改数据库时遇到的麻烦相比，现在使用它编写的工作量是最小的。

Answer 2

为切换数据库做好准备是可以为存储库模式提供的最烦人的参数之一。 这个通常是无知的“我永远不会切换数据库”。 如果我每次有这个对话时都有一个upvote ...

现在假设你想添加一个像缓存这样的后端或一些搜索引擎来优化搜索。 这非常适合存储库模式。

存储库模式的一般关键优势是与后端相关的所有更改都比其他更易于管理。

为了证明为什么你不想在模型中使用这些东西; 如果要迁移模型的属性，则需要以不同方式从后端获取模型。 在某些情况下，您可能需要两个模型。 当你将这一切都集中在一个模型中时，你需要应用大量的hackery来实现这一点。 如果存储库管理这些更改，模型将保持清晰，您的代码将再次变得易于管理。