2017-04-24 7 views
0

저장소 패턴에 대한 기사를 읽었으며 모델을 직접 호출하고 데이터를 반환 할 수있는 경우 생성자가 필요한 이유를 알고 싶습니다. 나는 또한 Book::all();$this->model->all()보다 적은 코드라고 생각한다. 그것은 단지 좋은 연습일까요 아니면 어떤 목적이 있습니까?Laravel 저장소 패턴

class BookRepository implements RepositoryInterface { 

    private $model; 

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

    public function index() 
    { 
     return $this->model->all(); 
    } 
} 

class BookRepository implements RepositoryInterface { 

    public function index() 
    { 
     return Book::all(); 
    } 
} 

답변

1

가장 큰 이유는 기본적으로 응용 프로그램이 그 depe을 충족하기 위해 제공해야 결정시키는 제어의 반전이다 주소. 이것이 중요한 이유는 코드를 리팩터링하기로 결정한 경우 Laravel에게 다른 구현을로드하도록 알릴 수 있기 때문입니다. 리포지터리 자체에서 코드를 변경할 필요가 없습니다.

그러나 이것은 클래스를 직접 사용하지 않고 대신 인터페이스를 사용하여 의존 관계를 선언한다는 아이디어로 연결됩니다. 그렇게하면 모든 구현을 스왑 아웃하고 코드를 읽을 수 있습니다.

class BookRepository { 

    public function __construct(BookInterface $book) 
    { 
     $this->book = $book; 
    } 

} 

는 이제 저장소 정말이 방법의 특정 세트가 정의 적용하는 책 인터페이스를 구현 단지, 실제 클래스에 대해 상관하지 않는다. 예를 들어, MySQL을 책의 데이터베이스로 사용하고 있지만 Postgres로 전환하면 기본 코드를 크게 변경해야하지만 기존의 이유로이 두 구현을 유지하려는 경우가 있습니다. Laravel에게 표준 Book 클래스 또는 새로운 PostgresBook 클래스를로드하도록 쉽게 말할 수 있습니다. 둘 다 여전히 BookInterface을 구현하기 때문에.

리포지토리를 전혀 변경할 필요가 없습니다. 바인드를 추가하면됩니다.

또 다른 직접적인 예는 Eloquent에서 ActiveRecord로 전환하기로 결정한 경우입니다.

0

모두 작동하지만 어떤 이유로 당신이 [의 myBook, 예를 들면 다른 모델로 모델 클래스 [도서]을 변경하려는 경우이 경우에, 당신은 변경됩니다 단지 생성자 매개 변수, 모든 기능하는 사용 [도서]

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