❝

프레임워크가 업데이트되었으며 프로젝트 구현도 이에 맞춰 진행되어야 합니다.

❞

Foreword

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

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

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

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

❝

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

❞

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

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

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

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

2년 동안 프레임워크를 사용한 후에도 Kaka는 여전히 프로젝트에서 가장 실용적인 두 가지 기능이 Facade와 미들웨어의 도입이라고 생각합니다.

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

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

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

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

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

"TP5.0 사용"

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

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

「TP5.1 사용법」SC를 도입한 후 직접 정적으로 메서드를 호출할 수 있습니다. SC는 몇 가지 간단한 구성을 수행하면 훨씬 간단하지 않습니다.

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

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

이것은 Kaka의 현재 프로젝트 디렉토리 구조입니다. 외부 레이어에 후크, 명령줄 구성, Facade 클래스를 저장하는 데이터 네임스페이스를 정의합니다. 및 모델, 서비스 클래스, 서비스 레이어, 도구 클래스, 검증 클래스

먼저 SC 클래스는 툴 클래스라는 점을 분명히 해야 합니다. 그러면 툴 클래스란 어떤 프로젝트에서나 사용할 수 있는 코드입니다. 그럼 파사드 클래스를 상속받아야 합니다 한 프로젝트에 파사드 클래스가 하나만 있을 수는 없습니다. 쉽게 사용할 수 있도록 파사드 클래스로 등록할 수 있는 것이 많습니다.

따라서 파사드에 등록해야 하는 모든 클래스를 등록하고 별칭을 지정할 수도 있는 후크를 작성해야 합니다. 위 그림에서 볼 수 있듯이 Config는 구성 파일을 로드하는 데 사용되므로 구성 파일은 반드시 필요합니다.

SC 클래스 파일을 구성 파일에 등록합니다. 아직 마지막 단계가 남았습니다. 후크가 정의되었지만 실행되지 않습니다.

이때, 어플리케이션 초기화 시 로드될 Hook 파일을 직접 설정해 주셔야 합니다.

지금까지 Facade가 구성되었습니다. 나중에 사용할 때는 SC::를 사용하여 메서드를 호출하면 됩니다.

❝

배움에 대한 끈기, 블로깅에 대한 끈기, 공유에 대한 끈기는 카카가 경력 이후부터 항상 지켜온 신념입니다. 누오다 인터넷에 있는 카카의 글이 여러분에게 조금이나마 도움이 되기를 바랍니다.

❞