Eloquent에 유용한 저장소가 있나요?

지난주에 글을 썼어요 Eloquent 엔터티에 대한 저장소 템플릿의 쓸모 없음에 대한 기사그러나 그는 그것을 부분적으로 활용하는 방법을 나에게 알려주겠다고 약속했습니다. 이를 위해 프로젝트에서 이 템플릿이 일반적으로 어떻게 사용되는지 분석해 보겠습니다. 저장소에 필요한 최소 메소드 세트:

<?php
interface PostRepository
{
    public function getById($id): Post;
    public function save(Post $post);
    public function delete($id);
}

그러나 실제 프로젝트에서는 저장소를 사용하기로 결정한 경우 레코드 검색 방법이 저장소에 추가되는 경우가 많습니다.

<?php
interface PostRepository
{
    public function getById($id): Post;
    public function save(Post $post);
    public function delete($id);

    public function getLastPosts();
    public function getTopPosts();
    public function getUserPosts($userId);
}

이러한 메소드는 Eloquent 범위를 통해 구현될 수 있지만 엔터티 클래스에 자신을 가져오는 책임을 오버로드하는 것은 최선의 아이디어가 아니며 이 책임을 저장소 클래스로 옮기는 것이 논리적으로 보입니다. 그렇습니까? 저는 구체적으로 이 인터페이스를 시각적으로 두 부분으로 나누었습니다. 메소드의 첫 번째 부분은 쓰기 작업에 사용됩니다.

표준 쓰기 작업은 다음과 같습니다.

• 새로운 사물의 건설과 도전 PostRepository::저장
• PostRepository::getById, 개체 조작 및 소환 PostRepository::저장
• 도전 PostRepository::삭제

쓰기 작업에서는 가져오기 메서드를 사용하지 않습니다. 읽기 작업에서는 get* 메서드만 사용됩니다. 에 대해 읽으면 인터페이스 분리 원리 (편지 I в 고체), 그러면 우리의 인터페이스가 너무 크고 적어도 두 가지 다른 책임을 수행한다는 것이 분명해질 것입니다. 이제 두 개로 나눌 차례입니다. 방법 getById 두 가지 모두에 필요하지만 애플리케이션이 더욱 복잡해지면 구현 방식도 달라집니다. 우리는 이것을 조금 나중에 보게 될 것입니다. 이전 글에서 쓰기 부분의 쓸모없음에 대해 썼기 때문에 이번 글에서는 그냥 잊어버리겠습니다.

읽기 부분은 그다지 쓸모가 없는 것 같습니다. Eloquent의 경우에도 여기에 여러 구현이 있을 수 있기 때문입니다. 수업 이름을 무엇으로 할까요? 할 수 있다 읽기포스트저장소, 그러나 템플릿에 저장소 그는 이미 관련성이 거의 없습니다. 당신은 할 수 있습니다 게시물 쿼리:

<?php
interface PostQueries
{
    public function getById($id): Post;
    public function getLastPosts();
    public function getTopPosts();
    public function getUserPosts($userId);
}

Eloquent로 구현하는 것은 매우 간단합니다:

<?php
final class EloquentPostQueries implements PostQueries
{
    public function getById($id): Post
    {
        return Post::findOrFail($id);
    }

    /**
    * @return Post[] | Collection
    */
    public function getLastPosts()
    {
        return Post::orderBy('created_at', 'desc')
            ->limit(/*some limit*/)
            ->get();
    }
    /**
    * @return Post[] | Collection
    */
    public function getTopPosts()
    {
        return Post::orderBy('rating', 'desc')
            ->limit(/*some limit*/)
            ->get();
    }

    /**
    * @param int $userId
    * @return Post[] | Collection
    */
    public function getUserPosts($userId)
    {
        return Post::whereUserId($userId)
            ->orderBy('created_at', 'desc')
            ->get();
    }
}

인터페이스는 구현과 연결되어야 합니다. 예를 들어 앱 서비스 제공자:

<?php
final class AppServiceProvider extends ServiceProvider 
{
    public function register()
    {
        $this->app->bind(PostQueries::class, 
            EloquentPostQueries::class);
    }
}

이 수업은 이미 유용합니다. 그는 컨트롤러나 엔터티 클래스를 구제함으로써 자신의 책임을 깨닫습니다. 컨트롤러에서는 다음과 같이 사용할 수 있습니다.

<?php
final class PostsController extends Controller
{
    public function lastPosts(PostQueries $postQueries)
    {
        return view('posts.last', [
            'posts' => $postQueries->getLastPosts(),
        ]);
    }
} 

방법 PostsController::lastPosts 구현을 요청하는 중입니다. 게시물 쿼리 그리고 그것으로 일합니다. 우리가 연결한 공급자에서 게시물 쿼리 수업과 함께 EloquentPost쿼리 이 클래스는 컨트롤러로 대체됩니다.

우리 애플리케이션이 매우 인기를 얻었다고 상상해 봅시다. 분당 수천 명의 사용자가 최신 출판물이 포함된 페이지를 엽니다. 가장 인기 있는 출판물도 매우 자주 읽혀집니다. 데이터베이스는 이러한 로드를 잘 처리하지 못하므로 표준 솔루션인 캐시를 사용합니다. 데이터베이스 외에도 특정 데이터 스냅샷은 특정 작업에 최적화된 스토리지에 저장됩니다. memcached 또는 홍채.

캐싱 로직은 일반적으로 그다지 복잡하지 않지만 EloquentPostQueries에서 이를 구현하는 것은 그다지 정확하지 않습니다(다음과 같은 이유 때문에). 단일 책임 원칙). 템플릿을 사용하는 것이 훨씬 더 자연스럽습니다. 데코레이터 기본 작업의 장식으로 캐싱을 구현합니다.

<?php
use IlluminateContractsCacheRepository;

final class CachedPostQueries implements PostQueries
{
    const LASTS_DURATION = 10;

    /** @var PostQueries */
    private $base;

    /** @var Repository */
    private $cache;

    public function __construct(
        PostQueries $base, Repository $cache) 
    {
        $this->base = $base;
        $this->cache = $cache;
    }

    /**
    * @return Post[] | Collection
    */
    public function getLastPosts()
    {
        return $this->cache->remember('last_posts', 
            self::LASTS_DURATION, 
            function(){
                return $this->base->getLastPosts();
            });
    }

    // другие методы практически такие же
}

인터페이스를 무시하세요 저장소 생성자에서. 알 수 없는 이유로 그들은 Laravel에서 캐싱을 위한 인터페이스 이름을 이런 방식으로 지정하기로 결정했습니다.

클래스 캐시된 게시물 쿼리 캐싱만 구현합니다. $this->캐시->기억하기 이 항목이 캐시에 있는지 확인하고 그렇지 않은 경우 콜백을 호출하고 반환된 값을 캐시에 씁니다. 남은 것은 이 클래스를 애플리케이션에 구현하는 것뿐입니다. 인터페이스 구현을 요청하려면 애플리케이션에 있는 모든 클래스가 필요합니다. 게시물 쿼리 클래스의 인스턴스를 받기 시작했습니다 캐시된 게시물 쿼리. 그러나 그 자신은 캐시된 게시물 쿼리 생성자는 클래스를 매개변수로 받아야 합니다. EloquentPost쿼리"실제" 구현 없이는 작동할 수 없기 때문입니다. 우리는 변화한다 앱 서비스 제공자:

<?php
final class AppServiceProvider extends ServiceProvider 
{
    public function register()
    {
        $this->app->bind(PostQueries::class, 
            CachedPostQueries::class);

        $this->app->when(CachedPostQueries::class)
            ->needs(PostQueries::class)
            ->give(EloquentPostQueries::class);
    }
}

내 모든 소원은 공급자에게 아주 자연스럽게 설명되어 있습니다. 따라서 우리는 하나의 클래스를 작성하고 컨테이너 구성을 변경하는 것만으로 요청에 대한 캐싱을 구현했습니다. 나머지 애플리케이션 코드는 변경되지 않았습니다.

물론 캐싱을 완벽하게 구현하기 위해서는 삭제된 글이 사이트에 한동안 머물지 않고 바로 삭제되도록 무효화도 구현해야 한다. 그러나 이것들은 사소한 것들입니다.

결론: 우리는 하나가 아닌 두 개의 템플릿을 사용했습니다. 견본 CQRS(명령 쿼리 책임 분리) 인터페이스 수준에서 읽기 및 쓰기 작업을 완전히 분리할 것을 제안합니다. 나는 그를 통해 그에게 왔습니다 인터페이스 분리 원리, 이는 패턴과 원리를 능숙하게 조작하고 하나를 정리로 도출한다는 것을 의미합니다 :) 물론 모든 프로젝트에 엔터티를 선택하기 위해 이러한 추상화가 필요한 것은 아니지만 그 요령을 여러분과 공유하겠습니다. 개발, 간단히 클래스를 만들 수 있습니다 게시물 쿼리 Eloquent를 통한 일반적인 구현:

<?php
final class PostQueries
{
    public function getById($id): Post
    {
        return Post::findOrFail($id);
    }

    // другие методы
}

캐싱이 필요할 때 간단한 이동으로 이 클래스 대신 인터페이스(또는 추상 클래스)를 만들 수 있습니다. 게시물 쿼리, 해당 구현을 클래스에 복사합니다. EloquentPost쿼리 앞서 설명한 구성표로 이동합니다. 나머지 애플리케이션 코드는 변경할 필요가 없습니다.

클래스, 인터페이스, 의존성 주입 и CQRS 에 자세히 설명 내 책 "복잡한 웹 애플리케이션의 아키텍처". 이 기사의 예제에 있는 모든 클래스가 최종 클래스로 표시되는 이유에 대한 수수께끼에 대한 해결책도 있습니다.

출처 : habr.com