Laravel은 모듈을 기반으로 API 아키텍처를 구현합니다.

저는 모듈식 설계를 기반으로 소프트웨어 및 프로그래밍 방법을 작성하는 것을 정말 좋아하지만 타사 소프트웨어 패키지 및 라이브러리에 의존하여 사소한 일을 처리하는 것을 별로 좋아하지 않습니다. 왜냐하면 프로그래밍 수준이 크게 향상되지 않기 때문입니다. . 그래서 저는 지난 2년 동안 Laravel에서 모듈 기반 소프트웨어를 작성해 왔으며 그 결과에 매우 만족합니다.

저를 모듈형 설계에 기반한 소프트웨어 및 프로그래밍 방법으로 이끄는 결정적인 요인은 프로그래밍 수준을 계속해서 향상시키고 싶다는 것입니다. 당신이 프로젝트 구조를 구축했는데 6개월 후에 프로젝트에 많은 버그가 있다는 것을 발견했다고 상상해 보십시오. 프로젝트 아키텍처는 일반적으로 6개월의 기존 코드에 영향을 주지 않고는 쉽게 변경되지 않습니다. 이 프로젝트를 분석하면서 저는 두 가지 주요 사항을 발견했습니다. 프로젝트 전반에 걸쳐 표준을 갖고 이를 고수하거나 모듈화하여 모듈별로 개선하는 것입니다.

어떤 사람들은 더 이상 좋아하지 않는 표준을 고수해야 함에도 불구하고 모든 비용을 들여 개발하고 표준을 고수하는 경향이 있습니다. 개인적으로 저는 지속적인 개선을 선호하며, 20번째 모듈이 첫 번째 모듈과 완전히 달라도 상관없습니다. 언젠가 버그를 수정하거나 리팩터링하기 위해 모듈 1로 돌아가야 하는 경우 모듈 20에서 사용되는 최신 표준으로 개선할 수 있습니다.

저처럼 여러분도 모듈화를 기반으로 Laravel 애플리케이션을 개발하고 프로젝트에 불필요한 타사 종속성을 최대한 추가하지 않는 것을 좋아한다고 가정해 보겠습니다. 이 기사는 약간의 제 경험입니다.

1- 라우팅 서비스 제공자

라라벨 라우팅 시스템은 전체 애플리케이션의 입구라고 할 수 있습니다. 가장 먼저 수정해야 할 것은 기존 경로를 모듈화해야 하는 기본 RouteServiceProvider.php 파일입니다.

<?php
namespace App\Providers;
use Illuminate\Support\Facades\Route;
use Illuminate\Foundation\Support\Providers\RouteServiceProvider as ServiceProvider;
class RouteServiceProvider extends ServiceProvider
{
    /**
     * 定义应用路由。
     *
     * @return void
     */
    public function map()
    {
        $this->mapModulesRoutes();
    }
    protected function mapModulesRoutes()
    {
        // 如果你在编写传统 Web 应用而非 HTTP API，请使用 `web` 中间件。 
        Route::middleware(&#39;api&#39;)
             ->group(base_path(&#39;routes/modules.php&#39;));
    }
}

위와 같이 이 파일의 전체 상용구를 제거하고 모듈식 라우팅 파일만 설정할 수 있습니다.

2- 모듈 파일

Laravel은 경로 폴더에 일부 파일과 함께 제공됩니다. 더 이상 RouteServiceProvider에서 이러한 경로를 매핑하지 않으므로 직접 삭제할 수 있습니다. 다음으로, module.php 라우팅 파일을 생성합니다.

<?php
use Illuminate\Support\Facades\Route;
Route::group([], base_path(&#39;app/Modules/Books/routes.php&#39;));
Route::group([], base_path(&#39;app/Modules/Authors/routes.php&#39;));

3- Books 모듈

앱 폴더에 Modules/Books/routes.php 파일을 생성하세요. 이 파일에서는 애플리케이션의 도서 모듈에 대한 라우팅 규칙을 정의할 수 있습니다.

<?php
use App\Modules\Books\ListBooks;
use Illuminate\Support\Facades\Route;
Route::get(&#39;/books&#39;, ListBooks::class);

라라벨의 기본 표준 라우팅 방법인 컨트롤러 기반 라우팅을 사용할 수 있지만, 저는 개인적으로 Good bye Controllers, Hello Request Handlers(컨트롤러를 버리고 요청 핸들러 사용) 방법을 선호합니다. 다음은 ListBooks의 구현입니다.

<?php
namespace App\Modules\Books;
use App\Eloquent\Book;
use App\Modules\Books\Resources\BookResource;
class ListBooks
{
    public function __invoke(Book $book)
    {
        return BookResource::collection($book->paginate());
    }
}

위 코드에서 BookResource는 라라벨의 리소스 변환 레이어입니다. 네임스페이스에 대한 공식 권장 사항에 따라 app/Modules/Books/Resources 폴더에 네임스페이스를 만들 수 있습니다.

<?php
namespace App\Modules\Books\Resources;
use Illuminate\Http\Resources\Json\Resource;
class BookResource extends Resource
{
    public function toArray($request)
    {
        return [
            &#39;id&#39; => $this->resource->id,
            &#39;title&#39; => $this->resource->title,
        ];
    }
}

4- Authors 모듈

Routes 파일을 통해 Authors 모듈을 시작할 수도 있습니다.

<?php
use App\Modules\Authors\ListAuthors;
use Illuminate\Support\Facades\Route;
Route::get(&#39;/authors&#39;, ListAuthors::class);

참고: app/Modules/Authors 네임스페이스는 우리가 작성한 파일을 나타내며 요청 핸들러에도 매우 간단합니다.

<?php
namespace App\Modules\Authors;
use App\Eloquent\Author;
use App\Modules\Authors\Resources\AuthorResource;
class ListAuthors
{
    public function __invoke(Author $author)
    {
        return AuthorResource::collection($author->paginate());
    }
}

마지막으로 작성된 Resource 클래스를 반응형 JSON 형식으로 변환합니다.

<?php
namespace App\Modules\Authors\Resources;
use App\Modules\Books\Resources\BookResource;
use Illuminate\Http\Resources\Json\Resource;
class AuthorResource extends Resource
{
    public function toArray($request)
    {
        return [
            &#39;id&#39; => $this->resource->id,
            &#39;name&#39; => $this->resource->name,
            &#39;books&#39; => $this->whenLoaded(&#39;books&#39;, function () {
                return BookResource::collection($this->resource->books);
            })
        ];
    }
}

BookResource를 재사용하기 위해 리소스가 다른 모듈로 어떻게 들어가는지 확인하세요. 모듈은 완전히 자급자족해야 하고 Eloquent 모델이나 모든 모듈에서 공통으로 사용되도록 설계된 일반 구성 요소와 같은 표준 클래스만 재사용할 수 있기 때문에 이는 일반적으로 좋은 선택이 아닙니다. 이 문제에 대한 해결책은 일반적으로 다른 모듈을 사용하지 않고도 변경이 이루어질 수 있도록 BookResource를 Authors 모듈에 복사하는 것입니다. 나는 이 교차 모듈 사용을 유지하기로 결정했습니다. 이 예는 모듈을 서로 격리된 상태로 유지하는 좋은 경험 법칙을 보여줍니다. 그러나 위의 예가 간단하고 문제가 발생할 가능성이 없다고 생각한다면. 다른 사람이 자신도 모르게 애플리케이션을 수정하는 것을 방지하기 위해 작성한 기능을 다루는 테스트를 항상 작성하십시오.

5- 결론

이것은 매우 간단한 예이지만 사람들이 자신의 필요에 따라 Laravel 프레임워크의 구조 표준을 쉽게 조작할 수 있기를 바랍니다. 모듈 기반 애플리케이션을 구축하기 위해 파일 위치를 매우 쉽게 변경할 수 있습니다. 내 프로젝트의 대부분은 모든 모듈에 대해 재사용 가능한 일반 기본 클래스에 사용할 수 있는 App/Components 모듈과 함께 제공됩니다. App/Eloquent, Modules 폴더는 Eloquent 모델 및 데이터베이스 관계형 모델을 저장하는 데 사용할 수 있습니다. 모듈성에 대해. 최근 작업을 시작한 앱의 폴더 디렉터리 구조는 다음과 같습니다.

모든 사람이 이 개념을 얻을 수 있기를 바랍니다. 각 모듈에는 고유한 요구 사항이 있으며 고유한 폴더/엔티티/클래스/메서드/속성이 있을 수 있습니다. 일부 모듈은 다른 모듈보다 훨씬 간단하고 광범위한 구조 설계가 필요하지 않기 때문에 모든 모듈을 정확히 동일하게 표준화할 필요는 없습니다. 이 예에서는 콘솔을 통해 Artisan 명령을 계속 제공하면서 HTTP 폴더를 통해 API를 제공하는 AccountChurn 모듈을 보여줍니다. 반면 AccountOverview는 HTTP API만 제공하고 창고, 값 개체(가방) 및 서비스 클래스(페이지네이터)를 사용하여 더 큰 데이터 가치를 제공합니다.

추천 튜토리얼: "PHP Tutorial" "Laravel Tutorial"

위 내용은 Laravel은 모듈을 기반으로 API 아키텍처를 구현합니다.의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!