저장소 디자인 패턴이 설명되어 있습니다-PHP 튜토리얼-php.cn

Repository Design Pattern Demystified

코어 포인트

창고 패턴은 응용 프로그램과 데이터 소스 사이의 중개자 역할을하므로 디퍼링 된 아키텍처를 구성하여 하드 코딩 된 종속성이 없어도 확장 성을 달성 할 수 있습니다.

이 모드를 사용하면 응용 프로그램이 데이터 소스의 세부 사항에주의를 기울이지 않고 저축을위한 데이터 수신 및 전송에 집중할 수 있습니다. 모든 사용자가 데이터 소스와 통신하는 공개 API (인터페이스)를 통해이를 수행합니다.

창고 패턴은 우려 분리 및 단위 테스트 용이성과 같은 이점을 제공하지만 소규모 응용 프로그램을 복잡하게 할 수있는 추상화 계층도 추가됩니다.

창고 패턴을 구현하려면 의존성 주입이 필요하므로 데이터웨어 하우스가 창고 인터페이스에 묶일 수 있습니다. 이는 하드 코딩 커플 링을 피하고 인터페이스 지향 프로그래밍을 용이하게합니다.

창고 모델은 무엇입니까?

간단히 말해서, 그것은 응용 프로그램과 데이터 소스 사이의 중개 계층의 구현입니다. 어느 당사자도 각각의 작업을 수행하기 위해 서로를 알아야 할 필요가 있으며, 이는 하드 코딩 된 종속성없이 대규모 응용 프로그램에서 확장하는 데 도움이되는 디퍼링 된 아키텍처를 가질 수 있습니다.

왜 그것에주의를 기울여야합니까?

예를 들어 이해합시다. 오렌지 맛 사탕을 판매하는 온라인 상점을 건설한다고 가정 해 봅시다. 현지 주식을 유지하는 작은 상점이므로 멋진 것은 필요하지 않습니다. Storefront 응용 프로그램은 데이터베이스에만 연결하고 기존 인벤토리를 기반으로 온라인으로 주문할 수 있습니다. 매장에는 하나의 공급 창고와 제한된 운영 지역이 있기 때문에 잘 작동합니다. 그러나 매장이 운영 영역을 확장하려면 어떻게됩니까? 상점은 다른 도시 나 전국으로 확장하기를 원할 수 있으며 중앙 인벤토리 시스템을 갖는 것은 매우 번거 롭습니다.

우리가 여전히 데이터 모델을 사용하는 경우 응용 프로그램이 다소 엄격하게 연결됩니다. 스토어 프론트 애플리케이션은 상호 작용 해야하는 모든 데이터 소스를 알아야합니다. 이는 애플리케이션 디자인이 좋지 않습니다. 매장 응용 프로그램의 임무는 고객이 사탕을 주문할 수 있도록하는 것입니다. 응용 프로그램은 데이터 소스에 신경 쓰지 않아야하며 모든 다른 데이터 소스를 추적해서는 안됩니다. 이것은 데이터웨어 하우스가 작동하는 곳입니다. 창고 패턴에 따르면, 공개 API는 인터페이스를 통해 노출되며 각 소비자 (이 경우 저장소 응용 프로그램)는이를 사용하여 데이터 소스와 통신합니다. 사용할 데이터 소스 또는 연결 방법은 응용 프로그램과 관련이 없습니다. 응용 프로그램은 얻는 데이터와 저장을 위해 보내는 데이터에만 관심이 있습니다.

창고 패턴이 구현되면 각 데이터 소스마다 창고를 만들 수 있습니다. 스토어 프론트 애플리케이션은 더 이상 데이터 소스를 추적 할 필요가 없으며 저장소 API를 사용하여 필요한 데이터를 얻습니다. 만병 통치약입니까?

아니요, 그렇지 않습니다. 모든 디자인 패턴과 마찬가지로 장단점이 있습니다.

프로 :

문제의 분리;

는 리포지토리가 런타임에 클래스를 주입하는 인터페이스에 묶여 있으므로 쉬운 단위 테스트를 허용합니다.

건조 (스스로 반복하지 않음) 디자인, 데이터 소스에서 데이터를 쿼리하고 얻는 코드는 반복되지 않습니다.

단점 :

다른 추상화 층을 추가하여 특정 수준의 복잡성을 추가하여 소규모 응용 프로그램에 비해 너무 복잡합니다.

어떻게 하는가? 간단한 코드 예제를 살펴 보겠습니다. 내 예에서 Laravel을 사용하여 탁월한 의존성 주입 기능을 이용하겠습니다. 최신 PHP 프레임 워크를 사용하는 경우 이미 종속성 주입/IOC 컨테이너가 있어야합니다. 창고 패턴을 구현하려면 의존성 주입이 필요합니다. 데이터웨어 하우스를 창고 인터페이스에 바인딩 할 수 없으며 전체 아이디어는 하드 코딩 커플 링을 피하기 위해 인터페이스 지향 프로그래밍입니다. 프레임 워크를 사용하지 않거나 선택한 프레임 워크에 IOC 컨테이너가없는 경우 상용 IOC 컨테이너를 사용할 수 있습니다 (각주 참조).

시작하자. 먼저 작곡가에서 네임 스페이스와 자동로드를 설정했습니다. Composer.json을 열고 PSR-4 자동로드를 네임 스페이스에 추가하십시오 (ClassMap 직후 AutoRoad 노드에서).

저장 후 터미널에서

이제 인터페이스가 있으므로 저장소를 만들 수 있습니다. 를 작성하십시오.

리포지토리를 인터페이스에 바인딩하려면 Laravel의 IOC 컨테이너를 사용합니다.

    "autoload": {
        "classmap": [
            "app/commands",
            "app/controllers",
            "app/models",
            "app/database/migrations",
            "app/database/seeds",
            "app/tests/TestCase.php"
        ],
        "psr-4": {
            "RocketCandy\": "app/RocketCandy"
        }
    },

로그인 후 복사

<<> 이제 인터페이스를 통해 저장소를 사용할 수 있습니다. composer dump-autoload -o에서 app/RocketCandy/Repositories/OrangeCandyRepository/

    "autoload": {
        "classmap": [
            "app/commands",
            "app/controllers",
            "app/models",
            "app/database/migrations",
            "app/database/seeds",
            "app/tests/TestCase.php"
        ],
        "psr-4": {
            "RocketCandy\": "app/RocketCandy"
        }
    },

로그인 후 복사

여기서 인터페이스를 컨트롤러에 주입하고 컨트롤러의 모든 함수에서 쿼리 데이터에 사용할 수있는 클래스 변수에 객체 참조를 저장합니다. 우리는 인터페이스를 리포지토리에 바인딩하기 때문에

리포지토리를 직접 사용하는 것과 같습니다. OrangeCandyRepository 이제 데이터 소스의 유형과 유형은 의 유일한 관심사입니다. 우리의 응용 프로그램은 인터페이스와 노출 된 API 만 알고 있으며 해당 API를 준수 해야하는 각 저장소. 창고는 런타임에 IOC 컨테이너에서 구문 분석되므로 인터페이스 창고 바인딩이 필요에 따라 설정 될 수 있으며 응용 프로그램은 데이터 소스의 변경 사항에주의를 기울일 필요가 없습니다 데이터 소스는 이제 데이터베이스, 웹 서비스 또는 차원 간 하이퍼 다타 파이프 라인이 될 수 있습니다. OrangeCandyRepository CityAOrangeCandyRepository 모든 경우가 적용되는 것은 아닙니다 저장소 패턴의 단점에서 언급했듯이 응용 프로그램에 약간의 복잡성이 추가됩니다. 따라서 작은 애플리케이션을 작성하고 있고 그것이 큰 곳으로 진화하는 것을 보지 못하는 경우 (여러 데이터 소스를 호출해야 할 수도 있음) 구현하지 않고 구식 데이터 모델을 고수하는 것이 좋습니다. 이해하는 것은 언제 사용 해야하는지 아는 것과 다릅니다. 이것은 응용 프로그램을 작성할 때 많은 문제를 절약하고 응용 프로그램을 유지하거나 확장 (또는 감소)해야 할 때 많은 문제를 절약하는 매우 편리한 설계 패턴이지만 모든 응용 프로그램에 대한 만병 통치약은 아닙니다. CityAOrangeCandyRepository 나는 위의 구현을 보여주기 위해 Laravel 특정 코드를 사용했지만 좋은 IOC 컨테이너에 대해 상당히 간단하고 유사합니다. 질문이 있습니까? 아래 의견에 넣으십시오.

각주 :

CityAOrangeCandyRepository OrangeCandyRepository 다음은 프레임 워크가 없거나 프레임 워크를 사용하지 않는 경우 사용할 수있는 일부 IOC 컨테이너 라이브러리입니다.

ornodi ray.di auryn 주사위 버킷 ding

<:> 제안 된 독서 :

도메인 구동 디자인을 빠르게 Eric Evans의 도메인 중심 디자인