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

时间:2014-02-17 07:57:06

标签: php dependency-injection laravel laravel-4 repository-pattern

我们举两个例子。

示例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 = new \Foo\FooModel()更改为$this->model = new \Bar\BarModel();,其中BarModel将包含不同系统的方法。

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

P.S。术语 model 仅用于Convenince。

2 个答案:

答案 0 :(得分:5)

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

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

然后通过所有控制器更改所有引用(即您的示例2)将是一件麻烦事。只需更改一次存储库(例如您的示例1)就好了。

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

答案 1 :(得分:5)

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

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

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

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