Composer+Git이 "서비스 클래스 라이브러리"를 생성하는 방법에 대한 자세한 설명

이 글은 composer튜토리얼 칼럼에서 Composer가 Git을 결합하여 "서비스 클래스 라이브러리"를 만드는 방법을 소개하는 글입니다. 필요한 친구들에게 도움이 되길 바랍니다!

소개

저는 PHP가 이제 엔지니어링 분야까지 진출했다고 늘 믿어왔습니다. 과거 PHP 개발자들은 속도를 아름다움으로 여겼고, 속도와 규모는 항상 모순적이었습니다. 오늘날의 PHP 프로젝트, 특히 대규모 프로젝트는 엔지니어링과 규모가 모두 필요한 수준으로 점차 발전해 왔습니다. 코드를 엔지니어링한다는 것은 점점 더 복잡한 아키텍처로 발전하는 것을 의미합니다. 복잡한 아키텍처의 경우 마이크로서비스가 좋은 선택인 경우가 많습니다.

최근 프로젝트에서 이 질문이 필요했어요. 지도 서비스를 개발해야 합니다. 물론 이 서비스는 단순한 클래스 라이브러리 형태가 아니라 자체 데이터베이스와 자체 서비스 인터페이스를 가지고 있습니다. 이 경우 가장 좋은 옵션은 서비스화입니다. 물론 Thrift, HTTP 등 서비스를 제공하는 방법은 다양합니다. 하지만 현재 부서 환경을 평가해 보니 PHP가 주류 언어이고 내 프로젝트의 진행도 상대적으로 빡빡합니다. 내 눈에는 Thrift, HTTP 및 기타 방법이 모두 네트워크 프로토콜을 사용하여 서비스 분리를 ​​달성하는 것 같습니다. 해결책. 나는 프로젝트가 명확하게 심각한 상태에 있지 않은 경우에는 이러한 접근 방식이 필요하지 않다고 생각합니다. 네트워크 프로토콜 서비스화 사용의 단점은 상당한 복잡성을 초래한다는 것입니다. 이러한 복잡성은 종종 인력, 물적 자원 및 시간에 대한 투자를 의미합니다. 그래서 개발을 위해 PHP 언어로 "서비스 클래스 라이브러리"를 제공할 수 있기를 바랍니다.

제가 생각하는 것은 PHP의 Composer입니다.

Composer 수정

서비스 라이브러리 만들기

우선 내 애플리케이션(xxx/main1이라는 이름)에서 "서비스 라이브러리"를 분리해야 합니다. (사실 저는 Services와 같은 디렉토리를 생성하려고 생각했습니다). 하지만 코드가 비즈니스 프로그램과 결합되면 인간의 게으름으로 인해 처음부터 끝까지 스스로 제어하기 어렵고, 애플리케이션에서 여러 가지 편리한 기능을 사용하지 않으려고 고집하는 느낌이 듭니다. 그래서 내 선택은 Git 저장소에 새 프로젝트를 만들고 이름을 xxx/mapService로 지정하는 것입니다.

composer.json

이제 두 개의 Git 프로젝트(xxx/main1 및 xxx/mapService)가 있습니다. main1의 작곡가.json 파일에 다음 문을 추가했습니다.

그리고 작곡가.json에 mapService 다음과 같습니다.

이 구성은 main1 프로젝트, mapService의 Git 주소 및 사용해야 하는 버전을 알려줍니다.

물론 다음 사항에 주의해야 합니다.

• dev-master는 mapService의 마스터 브랜치를 직접 사용한다는 의미입니다. mapService에 다른 태그가 있는 경우 여기에서 태그 정보를 사용할 수 있습니다
• repositories는 프로젝트의 주소입니다
• 여기 있는 서비스는 우리 회사에서 구축한 GitLab에 배치됩니다.
• mapService 아래 src 폴더의 네임스페이스는 xxxx용 \xxxx\MapService\ 및 PSR-4 지원
• mapService는 Illuminate/database

를 사용합니다. 마지막으로, 작곡가 업데이트 -vvv를 사용하여 필요한 mapService를 다운로드하고 공급업체 디렉터리에 넣습니다.

업데이트 및 수정

현재 편집기는 main1 프로젝트에 있습니다. mapService 프로젝트를 편집하거나 수정하고 이를 mapService의 마스터 브랜치에 병합하려면 vender/xxx/mapService 디렉토리에 직접 들어갈 수 있습니다. Git에 해당하는 작업을 수행합니다. 이를 통해 직접적인 코드 수정이 가능합니다.

독립적인 구성

이 구조적 조합은 수천 마일의 긴 행진을 완료하는 첫 번째 단계에 불과합니다. 나중에 더 중요한 것은 이 서비스를 작성할 때 mapService의 독립성을 유지하기 위해 main1의 모든 것을 사용하지 않아야 한다는 점을 항상 기억해야 한다는 것입니다(독립성은 서비스화에 필요한 조건 중 하나입니다). 예를 들어, 제가 직면한 첫 번째 문제는 구성 파일이 독립적이어야 한다는 것이었습니다.

제 구현 방법은 mapService에서 직접 Config 클래스를 생성하고, 이 클래스에 직접 구성을 작성하는 것입니다.

저는 항상 이 구성 파일의 구현이 약간 실망스럽다고 느꼈습니다. 이렇게 하면 이 구성 파일이 Git 라이브러리에 들어가기 때문입니다. 그러나 나는 정말로 더 나은 해결책을 생각할 수 없습니다. Laravel에는 ServiceProvider를 구현하여 Laravel의 config 폴더에 Config를 생성하는 방법이 있지만 이 방법은 Laravel에만 적용됩니다. 보편성은 없습니다. 반면에, 서비스가 어떤 데이터베이스를 사용하는지는 그 자체가 서비스의 일부이고, 서비스의 Git 라이브러리에 넣는 것과는 아무 상관이 없는 것 같습니다.

디렉터리 구조

디렉토리 구조는 위와 같습니다

• Configs는 구성 파일을 제공합니다
• Contracts는 인터페이스 프로토콜을 제공합니다
• Exceptions는 예외를 제공합니다
• Supports는 타사 메서드 또는 클래스 라이브러리를 제공합니다
• Models는 제공합니다 데이터베이스와의 상호 작용
• Node.php는 특정 인터페이스를 구현합니다

서비스에서 가장 중요한 것은 인터페이스 프로토콜입니다. 따라서 Contracts 폴더를 생성하고 제공된 서비스를 인터페이스하세요.

인터페이스의 예외 처리에서는 상호 작용에 오류 코드 대신 예외를 사용하도록 시도해야 합니다. 그리고 이러한 예외는 최대한 맞춤화되어야 합니다. 이런 방식으로 상위 수준에서 통일된 처리가 가능해집니다.

Thinking

저는 이 아키텍처 모델을 PHP 코드 수준의 서비스 지향 모델로 지정합니다. 적용 가능한 시나리오는 다음과 같아야 합니다.

• 사후 계획 서비스 기반
• 초기 인력과 사고로 빠른 개발을 유지하려는 시나리오

Git의 SubTree와 SubModule의 차이점

사실 이 세 가지 방법은 동일합니다. 끝 하나의 프로젝트를 다른 프로젝트의 클래스 라이브러리로 사용하십시오. SubTree 및 SubModule은 Git 솔루션입니다. Composer는 PHP 언어에 대한 솔루션으로, 프로젝트를 다른 프로젝트에 추가하는 기능 외에도 버전 추가, 종속성 솔루션 등의 솔루션도 제공합니다. 프로젝트가 PHP로 작성된 경우 Composer를 사용하는 것이 의심할 여지 없이 더 나은 선택입니다.

나중에 프로토콜 서비스화

내 mapService가 나중에 프로토콜 서비스가 되기를 원한다면 이 mapService 프로젝트를 SDK로 단순화할 수 있습니다. 상위 계층 비즈니스 로직의 경우 작곡가 업데이트를 사용하여 업데이트하면 됩니다.

서비스 등록 및 검색

여기서 "서비스 클래스 라이브러리"라고 부르는 것은 서비스 등록 문제를 해결하지 못합니다. 얼마나 많은 프로젝트에서 내 서비스를 사용하는지 알 수 없습니다. 이를 위해서는 추가 프로세스 작업이 필요할 수 있습니다.

위 내용은 Composer+Git이 "서비스 클래스 라이브러리"를 생성하는 방법에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!