Foreword

저는 2년 전에 TP5.0을 사용하여 백엔드를 구축했고 그것은 오늘날까지 사용되었습니다. 변화하고 싶지 않은 건 아니고, 단지 '게으르다'는 말 때문일 뿐입니다.

이번에 Kaka가 새로운 프로젝트를 작성하게 되어 영광이지만, 이전에 구축한 프레임워크를 계속 사용하고 글을 쓰면서 글쓰기를 중단합니다. 이전 프로젝트에서 검증된 사항을 최적화할 수 있습니다.

구조와 효율성 측면에서 모두 서서히 쇠퇴하고 있습니다. 새로 나오는 것은 확실히 실행 효율성, 코드 스타일, 프레임워크 구조 및 새로운 기능입니다.

단순히 개발 효율성을 위한 것이라고 논쟁하지 말고, 그대로 유지하고 편안함을 깨고 계속 전진하세요.

❝
Kaka는 이 로드맵에 따라 기사를 작성할 계획입니다. 나중에 보완되지 않은 지식 포인트가 추가되는 것을 발견했습니다. 또한 이를 보완하는 데 도움을 주시길 바랍니다. 댓글란에
❞

TP 프레임워크는 끊임없이 업데이트되지만 새 프로젝트의 사용은 변경되지 않습니다. — 여기에 그림 설명 삽입

1. 5.0과 5.1의 프레임워크 비교

6.0을 사용하지 않는 이유에 대해 논쟁하지 마세요

얘기 좀 해보자 먼저 KaKa가 프로젝트에서 경험한 변화에는 파사드 도입, 클래스 라이브러리 별칭, 모델 개선, 주석 라우팅, 미들웨어가 포함됩니다.

KaKa가 가장 최적화하고 싶은 부분이기도 합니다. 5.1은 여전히 5.0과 관련이 많습니다. 그림을 보세요!

TP 프레임워크는 끊임없이 업데이트되지만 새 프로젝트의 사용은 변경되지 않습니다. 2년 동안 프레임워크를 사용한 후에도 Kaka는 여전히 프로젝트에서 가장 실용적인 두 가지 기능이 Facade와 미들웨어의 도입이라고 생각합니다.

다음 단계는 Facade에 대한 간단한 소개입니다.

2. Facade에 대한 간단하고 대략적인 이해

원리를 분석하지는 않겠습니다. 나중에 분석할 특별 기사가 있으므로 먼저 세 번 연속으로 올 것입니다.

Facade의 기능은 인스턴스화 없이 클래스를 정적으로 호출할 수 있도록 하는 것입니다.

두 프레임워크를 사용한 구현 사례 비교

"TP5.0 사용"

툴 클래스를 소개한 후 한 번 인스턴스화해야 합니다. 나중에 사용할 때는 SC 클래스에서 메소드를 호출하는 것이 $this->session입니다.

이 메서드가 작동하지 않는다는 의미는 아닙니다. TP5.1의 효과를 살펴보겠습니다.

「TP5.1 사용법」 TP 프레임워크는 끊임없이 업데이트되지만 새 프로젝트의 사용은 변경되지 않습니다. SC를 도입한 후 직접 정적으로 메서드를 호출할 수 있습니다. SC는 몇 가지 간단한 구성을 수행하면 훨씬 간단하지 않습니다.

외관 설정 프로세스는 TP5.0의 직접 인스턴스화보다 조금 더 복잡하지만 매우 실용적입니다!

"TP5.1의 Facade를 구성하는 방법을 살펴보겠습니다."

이것은 Kaka의 현재 프로젝트 디렉토리 구조입니다. 외부 레이어에 후크, 명령줄 구성, Facade 클래스를 저장하는 데이터 네임스페이스를 정의합니다. 및 모델, 서비스 클래스, 서비스 레이어, 도구 클래스, 검증 클래스 TP 프레임워크는 끊임없이 업데이트되지만 새 프로젝트의 사용은 변경되지 않습니다.

먼저 SC 클래스는 툴 클래스라는 점을 분명히 해야 합니다. 그러면 툴 클래스란 어떤 프로젝트에서나 사용할 수 있는 코드입니다. TP 프레임워크는 끊임없이 업데이트되지만 새 프로젝트의 사용은 변경되지 않습니다. 그럼 파사드 클래스를 상속받아야 합니다 한 프로젝트에 파사드 클래스가 하나만 있을 수는 없습니다. 쉽게 사용할 수 있도록 파사드 클래스로 등록할 수 있는 것이 많습니다.

따라서 파사드에 등록해야 하는 모든 클래스를 등록하고 별칭을 지정할 수도 있는 후크를 작성해야 합니다. TP 프레임워크는 끊임없이 업데이트되지만 새 프로젝트의 사용은 변경되지 않습니다. 위 그림에서 볼 수 있듯이 Config는 구성 파일을 로드하는 데 사용되므로 구성 파일은 반드시 필요합니다.