ThinkPHP-31-PHP 튜토리얼-php.cn

기본:

1. 기본 개념

LAMP

LAMP는 Linux, Apache, MySQL 및 PHP를 기반으로 하는 개방형 리소스 네트워크 개발 플랫폼입니다. 이 용어는 이러한 프로그램이 표준 개발 환경으로 일반적으로 사용되었던 유럽에서 유래되었습니다. 이름은 각 프로그램의 첫 글자에서 파생됩니다. 각 프로그램은 소유권에 있어서 오픈 소스 표준을 준수합니다. Linux는 개방형 시스템이고, Apache는 가장 다재다능한 웹 서버이며, MySQL은 웹 기반 관리를 위한 추가 도구가 포함된 관계형 데이터베이스입니다. 웹 개발을 더욱 효율적으로 만들기 위해 다른 언어의 많은 최고의 기능을 사용합니다. Windows 운영체제의 Linux 환경에서 이러한 도구를 사용하는 개발자를 WAMP를 사용한다고 합니다.
이러한 오픈 소스 프로그램 자체는 다른 여러 프로그램과 함께 작동하도록 특별히 설계되지 않았지만 모두 영향력 있는 오픈 소스 소프트웨어이고 많은 공통 특성을 공유하기 때문에 이러한 구성 요소를 함께 사용하는 경우가 많습니다. 지난 몇 년 동안 이러한 구성 요소의 호환성은 지속적으로 향상되었으며 함께 사용하는 것이 더욱 보편화되었습니다. 그리고 서로 다른 구성 요소 간의 협업을 개선하기 위해 특정 확장 기능을 만들었습니다. 현재 이러한 제품은 거의 모든 Linux 배포판에 기본적으로 포함되어 있습니다. Linux 운영 체제, Apache 서버, MySQL 데이터베이스 및 Perl, PHP 또는 Python 언어 등 이러한 제품이 함께 강력한 웹 애플리케이션 플랫폼을 형성합니다.
오픈소스 열풍이 활발해지면서 오픈소스 LAMP는 J2EE, .Net 상용소프트웨어와 3자 대결 구도를 형성했으며, 소프트웨어 개발 프로젝트는 소프트웨어 투자비용이 저렴해 IT 전반에서 선호되고 있다. 커뮤니티에 집중하세요. 웹사이트 트래픽 측면에서 보면, 접속 트래픽의 70% 이상이 LAMP에서 제공되는 가장 강력한 웹사이트 솔루션입니다.

OOP

객체 지향 프로그래밍(OOP, 객체 지향 프로그래밍)은 컴퓨터 프로그래밍 아키텍처입니다. OOP의 기본 원칙은 컴퓨터 프로그램이 서브루틴 역할을 하는 개별 단위 또는 개체로 구성된다는 것입니다. OOP는 재사용성, 유연성, 확장성이라는 소프트웨어 엔지니어링의 세 가지 주요 목표를 달성합니다. 전반적인 작업을 실현하기 위해 각 개체는 정보를 수신하고, 데이터를 처리하고, 다른 개체에 정보를 보낼 수 있습니다. OOP는 주로 다음과 같은 개념과 구성 요소를 가지고 있습니다.
구성 요소 - 실행 중인 컴퓨터 프로그램에서 데이터와 기능이 함께 구성되는 단위입니다. 구성 요소는 OOP 컴퓨터 프로그램의 모듈과 구조의 기초입니다.
추상성 - 처리되는 정보의 특정 측면을 무시하는 프로그램의 능력, 즉 정보의 주요 측면에 집중하는 능력입니다.
캡슐화 - 정보 캡슐화라고도 함: 구성 요소가 예상치 못한 방식으로 다른 구성 요소의 내부 상태를 변경하지 않도록 보장합니다. 내부 상태 변경 방법을 제공하는 구성 요소만 내부 상태에 액세스할 수 있습니다. 각 구성 요소 유형은 다른 구성 요소와 통신하기 위한 인터페이스를 제공하고 다른 구성 요소가 호출할 메서드를 지정합니다.
다형성 - 구성 요소 참조 및 클래스 어셈블리에는 다양한 유형의 구성 요소가 포함되며 구성 요소를 참조하여 생성된 결과는 실제 호출 유형에 따라 달라집니다.
상속 - 기존 구성 요소를 기반으로 하위 클래스 구성 요소를 생성할 수 있어 다형성과 캡슐화를 통합하고 향상합니다. 일반적으로 클래스는 구성 요소를 그룹화하는 데 사용되며 새 클래스는 기존 클래스의 확장으로 정의될 수도 있으므로 클래스는 작업의 다양성을 반영하는 트리 또는 네트워크 구조로 구성될 수 있습니다.
구성 요소 기반 프로그래밍은 추상화, 캡슐화, 재사용성, 사용 용이성 등의 이유로 스크립팅 언어에서 특히 인기를 끌었습니다.

MVC

MVC는 애플리케이션의 입력, 처리, 출력을 분리하도록 하는 디자인 패턴입니다. MVC를 사용하는 애플리케이션은 모델(M), 뷰(V), 컨트롤러(C)의 세 가지 핵심 구성 요소로 나누어지며, 각 구성 요소는 자체 작업을 처리합니다.
보기: 보기는 사용자가 보고 상호 작용하는 인터페이스입니다. 기존 웹 애플리케이션의 경우 뷰는 HTML 요소로 구성된 인터페이스입니다. 새로운 스타일의 웹 애플리케이션에서는 HTML이 여전히 뷰에서 중요한 역할을 하지만 Adobe Flash 및 일부 마크업 언어를 비롯한 일부 새로운 기술이 끊임없이 등장했습니다. 및 XHTML, XML/XSL, WML 등과 같은 웹 서비스 애플리케이션의 인터페이스를 처리하는 방법이 점점 더 어려워지고 있습니다. MVC의 가장 큰 장점 중 하나는 애플리케이션에 대해 다양한 뷰를 처리할 수 있다는 것입니다. 데이터가 온라인에 저장되어 있든 직원 목록에 저장되어 있든 상관없이 뷰에서는 실제 처리가 발생하지 않습니다. 뷰는 데이터를 출력하고 사용자가 이를 조작할 수 있는 방법으로만 사용됩니다.
모델: 모델은 기업 데이터와 비즈니스 규칙을 나타냅니다. MVC의 세 가지 구성 요소 중에서 모델이 가장 많은 처리 작업을 수행합니다. 예를 들어 EJB 및 ColdFusion 구성 요소와 같은 구성 요소 객체를 사용하여 데이터베이스를 처리할 수 있습니다. 모델이 반환하는 데이터는 중립적입니다. 즉, 모델은 데이터 형식과 아무런 관련이 없으므로 모델은 여러 보기에 데이터를 제공할 수 있습니다. 모델에 적용된 코드는 한 번만 작성하면 여러 뷰에서 재사용할 수 있으므로 코드 중복이 줄어듭니다.
컨트롤러: 컨트롤러는 사용자 입력을 받아들이고 모델과 뷰를 호출하여 사용자의 요구를 충족합니다. 따라서 웹 페이지의 하이퍼링크를 클릭하고 HTML 양식이 전송되면 컨트롤러 자체는 아무것도 출력하거나 처리하지 않습니다. 요청을 수신하고 요청을 처리하기 위해 호출할 모델 구성 요소를 결정한 다음 모델 처리에서 반환된 데이터를 표시하는 데 사용할 뷰를 결정합니다.
이제 MVC 처리 프로세스를 요약합니다. 먼저 컨트롤러는 사용자의 요청을 수신하고 처리를 위해 어떤 모델을 호출해야 하는지 결정합니다. 그런 다음 모델은 비즈니스 로직을 사용하여 사용자의 요청을 처리하고 마지막으로 데이터를 반환합니다. 해당 뷰 형식은 모델에서 반환된 데이터가 변환되어 프레젠테이션 레이어를 통해 사용자에게 표시됩니다.

ORM

객체/관계 매핑(ORM)은 객체지향 소프트웨어 개발 방식의 발전으로 탄생했습니다. 객체지향 개발 방식은 오늘날 기업 수준 애플리케이션 개발 환경의 주류 개발 방식이고, 관계형 데이터베이스는 기업 수준 애플리케이션 환경에서 데이터를 영구적으로 저장하는 주류 데이터 저장 시스템이다. 개체와 관계형 데이터는 비즈니스 엔터티를 표현하는 두 가지 형태입니다. 비즈니스 엔터티는 메모리의 개체로 표시되고 데이터베이스의 관계형 데이터로 표시됩니다. 메모리에는 객체 간의 연관과 상속 관계가 있지만, 데이터베이스에서는 관계형 데이터가 다대다 연관과 상속 관계를 직접적으로 표현할 수 없습니다. 따라서 ORM(객체 관계형 매핑) 시스템은 일반적으로 미들웨어 형태로 존재하며 주로 프로그램 객체를 관계형 데이터베이스 데이터에 매핑하는 작업을 구현합니다.
객체 지향은 소프트웨어 공학의 기본 원리(예: 결합, 집합, 캡슐화)를 기반으로 개발된 반면 관계형 데이터베이스는 수학적 이론을 기반으로 개발되었습니다. 이러한 불일치 현상을 해결하기 위해 객체 관계형 매핑(Object Relational Mapping) 기술이 탄생했습니다.

AOP

AOP(Aspect-Oriented 프로그래밍, 관점 지향 프로그래밍)는 OOP(객체 지향 프로그래밍, 객체 지향 프로그래밍)를 보완하고 개선한 것이라고 할 수 있습니다. OOP는 캡슐화, 상속, 다형성과 같은 개념을 도입하여 일반적인 동작 모음을 시뮬레이션하기 위한 개체 계층 구조를 설정합니다. 분산된 개체에 공개 동작을 도입해야 할 때 OOP는 무력합니다. 즉, OOP에서는 위에서 아래로 관계를 정의할 수 있지만 왼쪽에서 오른쪽으로 관계를 정의하는 데는 적합하지 않습니다. 예를 들어 로깅 기능이 있습니다. 로깅 코드는 모든 개체 계층에 수평으로 분산되는 경향이 있으며, 분산되는 개체의 핵심 기능과는 아무런 관련이 없습니다. 보안, 예외 처리, 투명한 지속성 등 다른 유형의 코드에서도 마찬가지입니다. 이렇게 곳곳에 흩어져 있는 관련 없는 코드를 크로스커팅 코드(Cross-Cutting Code)라고 합니다. 이는 OOP 설계에서 많은 양의 코드를 중복하게 만들고 다양한 모듈의 재사용에 도움이 되지 않습니다. AOP 기술은 그 반대이다. "크로스커팅(cross-cutting)"이라는 기술을 사용해 캡슐화된 객체의 내부를 해부하고, 여러 클래스에 영향을 미치는 공용 행위를 재사용 가능한 모듈로 캡슐화하는데, 이름이 "Aspect"인데, 이는 "Aspect"라는 뜻이다. 측면. 간단히 말해서 소위 "측면"은 비즈니스와 관련이 없지만 일반적으로 비즈니스 모듈에서 호출되는 논리 또는 책임을 캡슐화하여 시스템에서 코드 중복을 줄이고 결합을 줄이는 것입니다. 모듈 간, 미래의 운용성 및 유지 관리성에 이점을 제공합니다. AOP는 수평 관계를 나타냅니다. "객체"가 객체의 속성과 동작을 캡슐화하는 속이 빈 원통형이라면 관점 지향 프로그래밍 방법은 날카로운 칼과 같습니다. 내부에 대한 정보를 얻으세요. 절단된 단면은 소위 "측면"입니다. 그런 다음 이러한 절단된 부분을 놀라운 기술로 복원하여 흔적을 남기지 않았습니다.
AOP는 "크로스 커팅" 기술을 사용하여 소프트웨어 시스템을 핵심 관심사와 크로스 커팅 관심사의 두 부분으로 나눕니다. 비즈니스 처리의 주요 프로세스가 핵심 관심사이고, 그것과 관련이 거의 없는 부분이 교차 관심사입니다. 교차 관심사의 한 가지 특징은 핵심 관심사 내의 여러 위치에서 발생하는 경우가 많으며 본질적으로 모든 곳에서 유사하다는 것입니다. 권한 인증, 로깅, 트랜잭션 처리 등이 있습니다. Aop의 역할은 시스템의 다양한 관심사를 분리하여 핵심 관심사와 교차 관심사를 분리하는 것입니다. Avanade의 수석 솔루션 설계자인 Adam Magee가 말했듯이 AOP의 핵심 아이디어는 "애플리케이션의 비즈니스 로직을 이를 지원하는 공통 서비스에서 분리"하는 것입니다. ”

CURD

CURD는 데이터베이스 기술의 약자로 일반적인 프로젝트 개발에 있어서 다양한 매개변수의 기본 기능이 CURD이다. 생성, 업데이트, 읽기 및 삭제 작업을 나타냅니다. CURD는 데이터 처리를 위한 기본 원자 연산을 정의합니다. CURD가 기술적인 어려움 수준으로 격상된 이유는 여러 데이터베이스 시스템에서 CURD 연산과 관련된 집계 관련 활동을 완료하는 성능이 데이터 관계의 변화에 따라 크게 달라질 수 있기 때문입니다.
CURD는 특정 애플리케이션에서 반드시 생성, 업데이트, 읽기, 삭제 메소드를 사용하는 것은 아니지만 이들이 수행하는 기능은 동일합니다. 예를 들어 ThinkPHP는 추가, 저장, 선택 및 삭제 메소드를 사용하여 모델의 CURD 작업을 나타냅니다.

ActiveRecord

Active Record(중국명: Active Record)는 관계형 데이터베이스 테이블에 해당하는 모델 클래스가 특징인 도메인 모델 패턴이며, 모델 클래스의 인스턴스는 테이블의 행에 해당합니다. Active Record와 Row Gateway는 매우 유사하지만 전자는 도메인 모델이고 후자는 데이터 소스 모델입니다. 관계형 데이터베이스는 외래 키를 통해 엔터티 관계를 표현하는 경우가 많으며 Active Record는 이 관계를 데이터 소스 수준의 개체 연결 및 집계에 매핑합니다. Active Record는 매우 간단한 도메인 요구 사항, 특히 도메인 모델과 데이터베이스 모델이 매우 유사한 경우에 적합합니다. 더 복잡한 도메인 모델 구조(예: 상속 및 전략을 사용하는 도메인 모델)가 발생하는 경우 데이터 소스를 분리하고 이를 데이터 매퍼와 결합하는 도메인 모델을 사용해야 하는 경우가 많습니다.
Active Record 드라이버 프레임워크는 일반적으로 ORM 프레임워크의 기능을 가지고 있지만, Active Record는 Row Gateway와의 차이점처럼 단순한 ORM이 아닙니다. Rails에서 처음 제안한 이 모델은 표준 ORM 모델을 따릅니다. 즉, 테이블은 레코드에 매핑되고, 레코드는 개체에 매핑되며, 필드는 개체 속성에 매핑됩니다. 다음과 같은 명명 및 구성 규칙을 사용하면 모델의 작동을 광범위하게 신속하게 실현할 수 있으며 간단하고 이해하기 쉽습니다.

단일입장

단일 항목은 일반적으로 프로젝트 또는 애플리케이션에 통합된(반드시 고유하지는 않은) 항목 파일이 있음을 의미합니다. 즉, 프로젝트의 모든 기능적 작업이 이 항목 파일을 통해 수행되며 종종 항목 파일이 첫 번째 1단계인 경우가 많습니다. 실행됩니다.
단일 출입구의 장점은 동일한 출입구가 다양한 운영에 대해 동일한 규칙을 갖는 경우가 많기 때문에 전체 프로젝트가 더욱 표준화된다는 것입니다. 또 다른 측면은 단일 진입의 장점은 차단이 편리하고 일부 권한 제어, 사용자 로그인 등의 판단 및 작업을 일률적으로 처리할 수 있기 때문에 제어가 더 유연하다는 것입니다.
하나의 항목 파일로 모든 웹사이트에 접속할 수 있지 않을까 걱정하시는 분들도 계시는데, 사실 이는 근거 없는 생각입니다.

2. 디렉토리 구조

目录/文件	说明
ThinkPHP.php	框架入口文件
Common	框架公共文件目录
Conf	框架配置文件目录
Lang	框架系统语言目录
Lib	系统核心基类库目录
Tpl	系统模板目录
Extend	框架扩展目录（关于扩展目录的详细信息请参考后面的扩展章节）

참고: 코어 버전을 다운로드하는 경우 ThinkPHP 자체는 확장 기능에 의존하지 않기 때문에 확장 디렉터리가 비어 있을 수 있습니다.

3. 명명 규칙

ThinkPHP를 사용하여 개발할 때는 다음 명명 규칙을 따라야 합니다. 🎜>

클래스 파일에는 모두 .class.php라는 접미사가 붙습니다(이는 ThinkPHP에서 내부적으로 사용하는 클래스 라이브러리 파일을 의미하며 외부에서 로드되는 클래스 라이브러리 파일을 나타내지 않습니다). 대소문자 및 DbMysql.class.php;
와 같은 첫 번째 대문자는 Unix 계열 시스템이 대소문자를 구분하므로 파일 이름 지정 및 호출이 대소문자를 일관되게 유지하도록 합니다( ThinkPHP는 디버깅 모드에서 Windows 플랫폼에서도 대소문자를 엄격하게 검사합니다.
클래스 이름은 위에서 언급한 대소문자를 포함하여 파일 이름과 일치합니다. , UserAction 클래스의 파일 이름은 UserAction.class.php이고, InfoModel 클래스의 파일 이름은 InfoModel.class.php이며, 다양한 클래스 라이브러리에는 클래스 이름 지정에 대한 특정 표준이 있습니다. 🎜> 함수, 구성 파일 및 기타 클래스 라이브러리 파일 이외의 파일에는 일반적으로 .php 접미사가 붙습니다(제3자가 도입한 접미사는 필수가 아닙니다).
함수 이름은 소문자와 get_client_ip와 같은 밑줄;
메서드 이름은 카멜 표기법을 사용하여 지정되며, 첫 번째 문자는 소문자이거나 밑줄 "_"가 사용됩니다(예: getUserName, _parseType). 밑줄은 비공개 메서드입니다.
속성 이름을 지정할 때 카멜 표기법을 사용하고, 첫 번째 문자는 소문자이거나 밑줄 "_"를 사용해야 합니다(예: tableName, _instance). 밑줄은 비공개 속성입니다.
이중 밑줄 "__"로 시작하는 함수나 메서드는 __call 및 __autoload와 같은 매직 메서드로 사용됩니다.
상수 이름은 HAS_ONE 및 MANY_TO_MANY와 같이 대문자와 밑줄로 명명됩니다.
구성 매개변수는 HTML_CACHE_ON과 같이 대문자와 밑줄로 명명됩니다. >
데이터 테이블과 필드의 이름은 소문자로 밑줄이 그어져 있으며 필드 이름은 밑줄로 시작하지 않습니다(예: think_user 테이블 및 user_name 필드, _username과 같은 데이터 테이블 필드). 필터링됩니다.
ThinkPHP에는 단일 문자 대문자 함수인 함수 이름 지정의 특별한 경우가 있습니다. 이러한 유형의 함수는 일반적으로 단축키입니다. 특정 작업의 정의 또는 특수 기능이 있습니다. 예를 들어 ADSL 방식 등이 있습니다.

4. CBD 아키텍처

ThinkPHP3.0 버전에서는 새로운 CBD(Core Behavior Behavior Driver) 아키텍처 모델을 도입했습니다. 최하위 계층에서 프레임워크는 핵심 동작 기반 아키텍처 시스템을 채택합니다. 코어는 가장 중요한 부분을 유지하고 이를 표시하기 위해 중요한 위치에 레이블을 설정합니다. 다른 기능은 동작 확장 및 드라이버를 사용하여 결합됩니다. 필요한 경우 특정 라벨 위치의 동작을 확장하거나 교체하여 프레임워크의 하단 레이어를 쉽게 사용자 정의하거나 애플리케이션 레이어에 자체 라벨 위치와 애플리케이션 행을 추가할 수 있습니다. 레이블 위치는 AOP 개념의 "측면"과 유사하며 동작은 이 "측면"을 중심으로 프로그래밍됩니다. 시스템에 내장된 핵심 확장이 표준 모드로 간주되면 사용자는 이를 사용할 수 있습니다. 모든 동작 사용자 정의는 다음과 같습니다. 실제로 패턴 확장은 동작을 대체하고 추가할 수 있을 뿐만 아니라 사용자 정의된 사용자 정의 목적을 달성하기 위해 기본 MVC를 대체하고 수정할 수도 있습니다. 이 새로운 기능을 사용하면 개발자는 패턴 확장을 통해 자신이나 회사를 위한 개발 프레임워크를 쉽게 사용자 정의할 수 있습니다. 패턴 확장의 새 버전은 프레임워크 확장의 대가이며, 이것이 바로 새 버전의 진정한 아름다움입니다. .

5. 개발 프로세스

ThinkPHP를 사용하여 애플리케이션을 만드는 일반적인 개발 프로세스는 다음과 같습니다.

시스템 설계, 데이터베이스 및 데이터 테이블 생성( 선택사항) )

프로젝트 이름을 지정하고 프로젝트 항목 파일을 생성한 후 디버깅 모드를 켜세요.

프로젝트 구성을 완료하세요. >

프로젝트 함수 라이브러리 생성(선택 사항)
프로젝트에 필요한 확장(모드, 드라이버, 태그 라이브러리 등)을 개발합니다. 선택 사항)
컨트롤러 클래스 생성
모델 클래스 생성(선택 사항)
생성 템플릿 파일
실행 및 디버그, 로그 분석
캐시 기능 개발 및 설정(선택 사항)
라우팅 지원 추가(선택 사항)
보안 검사(선택 사항)
프로덕션 환경에 배포합니다.

6. 항목 파일

ThinkPHP는 어떤 기능이 완료되더라도 단일 항목 모드를 사용하여 프로젝트를 배포합니다. 프로젝트 통일된(반드시 고유하지는 않은) 입구를 갖습니다. 모든 프로젝트는 항목 파일에서 시작되며 모든 프로젝트의 항목 파일은 유사합니다. 항목 파일에는 주로

프레임워크 경로, 프로젝트 경로 및 프로젝트 정의가 포함됩니다. 이름(선택)
디버깅 모드 및 실행 모드 관련 상수 정의(선택)
프레임워크 항목 파일 로드(필수)

7. 프로젝트 디렉터리

생성된 프로젝트 디렉터리 구조는 다음을 포함하여 시스템 디렉터리와 유사합니다.

目录	说明
Common	项目公共文件目录，一般放置项目的公共函数
Conf	项目配置目录，项目所有的配置文件都放在这里
Lang	项目语言包目录（可选如果不需要多语言支持可删除）
Lib	项目类库目录，通常包括Action和Model子目录
Tpl	项目模板目录，支持模板主题
Runtime	项目运行时目录，包括Cache（模板缓存）、Temp（数据缓存）、Data（数据目录）和Logs（日志文件）子目录，如果存在分组的话，则首先是分组目录。

index.php를 앱 디렉터리 외부로 이동해야 하는 경우 항목 파일에 프로젝트 이름과 프로젝트 경로 정의만 추가하면 됩니다.

//프로젝트 이름 정의
정의('APP_NAME' , '앱');
//프로젝트 경로 정의
정의('APP_PATH', './App/');
//파일에 프레임 로드
require './App/ThinkPHP/ThinkPHP.php';

APP_NAME은 프로젝트 이름을 나타냅니다. APP_NAME은 임의로 설정하면 안 됩니다. 일반적으로 프로젝트가 웹 루트 디렉터리 아래에 직접 배포되는 경우 APP_NAME을 설정해야 합니다. 비우다.
APP_PATH는 프로젝트 경로를 나타냅니다("/"로 끝나야 함). 프로젝트 경로는 프로젝트 항목 파일의 위치가 아닌 프로젝트의 Common 및 Lib 디렉터리 위치를 나타냅니다.
참고: 런타임 디렉터리에는 Unix 계열 또는 Linux 환경에서 쓰기 가능한 권한이 필요합니다.

8. 배포 디렉터리

目录/文件	说明
ThinkPHP	系统目录（下面的目录结构同上面的系统目录）
Public	网站公共资源目录（存放网站的Css、Js和图片等资源）
Uploads	网站上传目录（用户上传的统一目录）
Home	项目目录（下面的目录结构同上面的应用目录）
Admin	后台管理项目目录
…… 更多的项目目录
index.php	项目Home的入口文件
admin.php	项目Admin的入口文件
…… 更多的项目入口文件

프로젝트의 템플릿 파일은 여전히 프로젝트의 Tpl 디렉토리에 배치되지만 이미지, JS 및 CSS를 포함하여 외부에서 호출되는 리소스 파일은 웹사이트의 공개 디렉토리 Public 디렉토리에 배치되고 Images에 저장됩니다. Js 및 Css 하위 디렉터리. 가능하다면 이러한 리소스 파일을 원격 호출을 위해 외부 서버에 배치하고 최적화할 수도 있습니다.

실제로 시스템 디렉토리와 프로젝트 디렉토리는 WEB 이외의 액세스 디렉토리 아래에 배치할 수 있습니다. Public 디렉토리와 항목 파일만 웹사이트 디렉토리 아래에 배치하면 보안이 향상됩니다. 웹사이트.

디렉터리를 직접 설정하려면 항목 파일에서 RUNTIME_PATH 상수를 변경할 수 있습니다. 예:

define('RUNTIME_PATH','./ App/temp/ ');

RUNTIME_PATH 디렉터리는 쓰기 가능한 권한으로 설정되어야 합니다.
컴파일 캐시 디렉터리 사용자 정의 외에도 컴파일 캐시 파일 이름 사용자 정의도 지원합니다. 예:

define('RUNTIME_FILE','./App/temp/ Runtime_cache.php');

ThinkPHP 프레임워크의 모든 구성 파일 정의 형식은 PHP 배열을 반환하는 것입니다.

// 프로젝트 구성 파일
return array(
'DEFAULT_MODULE' => 'Index', //기본 모듈
'URL_MODEL' => '2', //URL 모드
'SESSION_AUTO_START' =>
//추가 구성 매개변수
//...
);

구성 매개변수는 대소문자를 구분하지 않습니다(대문자 또는 소문자 정의에 관계없이 소문자로 변환되기 때문)

구성 파일 차원 배열에서 두 개를 사용하여 추가 정보를 구성할 수도 있습니다. 예:

//项目配置文件
 return array(
    &#39;DEFAULT_MODULE&#39;     => &#39;Index&#39;, //默认模块
    &#39;URL_MODEL&#39;          => &#39;2&#39;, //URL模式
    &#39;SESSION_AUTO_START&#39; => true, //是否开启session
    &#39;USER_CONFIG&#39;        => array(
        &#39;USER_AUTH&#39; => true,
        &#39;USER_TYPE&#39; => 2,
    ),
    //更多配置参数
    //...
 );

로그인 후 복사

보조 매개변수 구성은 다음과 같습니다. 대소문자를 구분합니다. 즉, 정의와 일치하는지 확인하세요.

9. 기존 구성과 프로젝트 구성, 디버깅 구성

시스템에서는 구성보다 관례가 중요합니다. 생각해보면 시스템에는 대부분의 용도에 따라 기본적으로 공통 매개변수를 구성하는 컨벤션 구성 파일(시스템 디렉토리 아래에 있는 Confconvention.php)이 내장되어 있습니다.

프로젝트 구성 파일은 가장 일반적으로 사용되는 구성 파일입니다. 프로젝트 구성 파일은 프로젝트의 구성 파일 디렉터리 Conf에 있으며 파일 이름은 config.php입니다.
프로젝트 구성 파일에 내장된 매개변수 구성을 추가하는 것 외에도 프로젝트에 필요한 추가 구성 매개변수를 추가할 수도 있습니다.

애플리케이션 상태가 구성되지 않은 경우 시스템은 기본적으로 디버그 상태로 설정됩니다. 즉, 기본 구성 매개변수는 다음과 같습니다.

&#39;APP_STATUS&#39; => &#39;debug&#39;, //应用调试模式状态

로그인 후 복사

debug.php 구성 파일만 프로젝트 구성 파일과 시스템 디버깅 구성 파일에서 다른 매개변수나 새 매개변수를 구성해야 합니다.

테스트 상태 등 디버그 모드에서 애플리케이션 상태를 추가하려면 프로젝트 구성 파일에서 다음과 같이 설정을 변경하면 됩니다.

&#39;APP_STATUS&#39; => &#39;test&#39;, //应用调试模式状态

로그인 후 복사

디버그 모드에는 캐시가 없기 때문에 더 많은 파일 IO 작업과 템플릿 실시간 컴파일이 필요하므로 디버그 모드를 켜면 성능은 어느 정도 감소하지만 배포 모드의 성능에는 영향을 미치지 않습니다.

참고: 디버깅 모드가 꺼지면 프로젝트의 디버깅 구성 파일이 즉시 무효화됩니다.

10. 그룹 구성 및 읽기 구성, 동적 구성

모듈 그룹화가 활성화된 경우 그룹 구성 파일은
프로젝트 구성 디렉터리/그룹 이름/config.php
다음 구성을 통해 그룹화를 활성화할 수 있습니다.

&#39;APP_GROUP_LIST&#39; => &#39;Home,Admin&#39;, //项目分组设定
 &#39;DEFAULT_GROUP&#39;  => &#39;Home&#39;, //默认分组

로그인 후 복사

이제 홈 및 관리자 그룹이 정의되었으므로 다음과 같이 그룹 구성 파일을 정의할 수 있습니다.

Conf/Home/config.php
Conf/Admin/config.php

로그인 후 복사

각 그룹의 구성 파일은 다음과 같습니다. 현재 그룹에서만 유효하며 그룹 구성의 정의 형식은 프로젝트 구성과 동일합니다.
참고: 그룹 이름은 대소문자를 구분하며 정의된 그룹 이름과 일치해야 합니다.

구성 파일을 정의한 후 시스템에서 제공하는 C 방법을 사용할 수 있습니다(이상하다고 생각되면 기억을 돕기 위해 Config 단어를 사용할 수 있음).

C('매개변수 이름')//설정된 매개변수 값을 가져옵니다

예를 들어 C('APP_STATUS')는 시스템의 디버그 모드를 읽습니다. 설정값이 아직 APP_STATUS가 없으면 NULL을 반환합니다.

C 방법을 사용하여 2차원 구성을 읽을 수도 있습니다.

C('USER_CONFIG.USER_TYPE') //사용자 구성에서 사용자 유형 설정 가져오기

구성 매개변수는 전역적으로 유효하므로 C 메서드는 설정 매개변수가 만료된 경우에도 어디에서나 모든 구성을 읽을 수 있습니다.

특정 Action 메소드에서는 특정 매개변수, 주로 아직 사용되지 않은 매개변수를 동적으로 구성할 수 있습니다.
새 값 설정:

C('매개변수 이름','새 매개변수 값');

예를 들어, 데이터 캐시의 유효 기간을 동적으로 변경해야 하는 경우

C('DATA_CACHE_TIME','60');

<을 사용할 수 있습니다. 🎜>

은 다음과 같이 도트 구문을 사용하여 2차원 배열의 읽기 및 설정을 지원할 수도 있습니다.

설정된 매개변수 값 가져오기:

C(' USER_CONFIG.USER_TYPE');

새 값 설정:

C('USER_CONFIG.USER_TYPE' ,'1');

C 함수는 버전 3.1부터 일괄 설정에만 유효한 구성 저장 기능을 지원합니다. 사용하려면:

C($array,'name');

여기서 array는 배치를 저장하는 배열 변수입니다. 구성 매개변수 목록을 이름으로 식별되는 캐시 데이터로 설정

캐시된 설정 목록 데이터를 얻으려면

C('','name') //또는 사용할 수 있습니다. C(null,'name');

은 이름으로 식별된 캐시 구성 데이터를 현재 구성 데이터로 읽습니다(병합).

11. 확장 구성

프로젝트 구성 파일은 배포 모드 중에 컴파일 캐시에 포함됩니다. 즉, 컴파일 후에 프로젝트 구성 파일을 수정하면 즉시 적용되지 않습니다. 적용하려면 먼저 컴파일 캐시를 삭제해야 합니다. 확장 구성 파일은 이 제한의 영향을 받지 않습니다. 배포 모드에서도 수정된 구성은 실시간으로 적용될 수 있으며 구성 형식은 프로젝트 구성과 동일합니다.

확장 구성을 설정하는 방법은 다음과 같습니다(여러 파일을 쉼표로 구분):

'LOAD_EXT_CONFIG' => 'user,db', // 확장 구성 파일 로드

프로젝트는 각각 사용자 구성 및 데이터베이스 구성을 위해 확장 구성 파일 user.php 및 db.php를 로드하도록 설정되어 있으며, 그 다음 구성 파일 Conf/user.php 및 db.php는 아래에 있습니다. 프로젝트 구성 디렉터리가 자동으로 로드됩니다.

보조 구성 방법을 사용하려면 다음과 같이 설정하면 됩니다.

'LOAD_EXT_CONFIG' => array(
'USER' => '사용자', //사용자 구성
'DB' => 'db', //데이터베이스 구성
), //확장 구성 파일 로드

user.php 구성 파일 내용은 동일하지만 사용자 매개변수를 얻는 최종 방법은 다음과 같습니다.

C('USER.USER_AUTH_ID');

이 방법을 사용하면 대규모 프로젝트 상황에서 매개변수 충돌 문제를 피할 수 있습니다.

아래 구성 파일 중 일부는 시스템에서 이미 사용하고 있으므로 사용자 정의 확장 구성으로 재정의하지 마십시오.

12. 함수 라이브러리

ThinkPHP의 함수 라이브러리는 시스템 함수 라이브러리와 프로젝트 함수 라이브러리로 나눌 수 있습니다.

시스템 함수 라이브러리

라이브러리 시스템 함수 라이브러리는 시스템의 Common 디렉터리에 있습니다:
common.php. 기본 함수 라이브러리는 언제든지 직접 호출할 수 있습니다.
functions.php는 프레임워크 표준 모드의 공용 함수 라이브러리입니다. 다른 모드에서는 자체 공용 함수 라이브러리를 대체하고 로드할 수 있습니다. 공개 함수 라이브러리
runtime.php는 디버깅 모드나 컴파일 프로세스에서만 로드되는 프레임워크 런타임 파일이므로 해당 파일의 메서드를 프로젝트에서 직접 호출할 수 없습니다. >

프로젝트 함수 라이브러리

라이브러리 프로젝트 함수 라이브러리는 일반적으로 프로젝트의 Common 디렉터리에 위치합니다. 파일 이름은 common.php입니다. 이 파일은 실행 중에 자동으로 로드되고 병합됩니다. 프로젝트 컴파일 통합 캐시. 그룹 배포 방법을 사용하는 경우 이 디렉터리에 "그룹 이름/function.php" 파일이 있으며 이 파일도 현재 그룹의 실행에 따라 자동으로 로드되므로 프로젝트 함수 라이브러리는 수동 로딩 없이 바로 사용할 수 있습니다.

프로젝트 구성에서 동적 함수 로딩 구성을 사용하는 경우 프로젝트 Common 디렉터리에 더 많은 함수 파일이 있을 수 있으며 동적으로 로드된 함수 파일은 컴파일 캐시에 포함되지 않습니다.

특수한 경우 모드에서 자동으로 로드되는 프로젝트 라이브러리의 위치나 이름을 변경할 수 있습니다.

확장 함수 라이브러리

라이브러리 필요할 때 로드 및 호출을 용이하게 하기 위해 프로젝트 공개 디렉토리 아래에 확장 함수 라이브러리를 정의할 수 있습니다. 확장 함수 라이브러리의 함수 정의 사양은 함수 라이브러리 파일 이름을 임의로 지정할 수 있다는 점을 제외하면 프로젝트 함수 라이브러리와 동일합니다. 일반적으로 확장 함수 라이브러리는 동적 로딩을 설정하지 않으면 자동으로 로드되지 않습니다. .

함수 로딩

시스템 함수 라이브러리와 프로젝트 함수 라이브러리의 함수는 프로젝트의 확장 함수 라이브러리를 로딩하지 않고 직접 호출할 수 있습니다. 다음 두 가지 호출 방법을 사용할 수 있습니다.

동적 로딩

프로젝트 구성 파일에서 LOAD_EXT_FILE 매개변수를 정의할 수 있습니다. 예:

"LOAD_EXT_FILE"=> "user,db"

위 설정을 통해 프로젝트의 public 디렉터리에 있는 확장 함수 라이브러리 파일인 user.php, db.php가 실행 시 자동으로 로딩되도록 하여, 프로젝트에서 직접 호출할 수 있습니다. 이제 확장 함수 라이브러리 user.php 및 db.php의 함수를 사용할 수 있으며 확장 함수 라이브러리의 함수 수정 사항이 실시간으로 적용됩니다.

개별 모듈에서 가끔씩만 함수를 사용하는 경우 자동 로딩을 사용할 필요가 없습니다. 다음과 같이 호출해야 할 때 수동으로 로드할 수 있습니다.

load("@.user")

@.user는 현재 프로젝트의 사용자 함수 파일을 로드하는 것을 의미합니다. user.php 함수 라이브러리는 직접 확장될 수 있습니다.

13. 클래스 라이브러리

ThinkPHP의 클래스 라이브러리에는 기본 클래스 라이브러리와 애플리케이션 클래스 라이브러리가 포함됩니다.

기본 클래스 라이브러리

类库	规则	示例
控制器类	模块名 Action	例如 UserAction、InfoAction
模型类	模型名 Model	例如 UserModel、InfoModel
行为类	行为名 Behavior	例如CheckRouteBehavior
Widget类	Widget名 Widget	例如BlogInfoWidget
驱动类	引擎名驱动名	例如DbMysql表示mysql数据库驱动、CacheFile表示文件缓存驱动

기본 클래스 라이브러리는 ThinkPHP의 핵심 기본 클래스 라이브러리와 확장 기본 클래스 라이브러리를 포함하여 ThinkPHP 클래스 라이브러리 사양을 준수하는 시스템 클래스 라이브러리를 의미합니다. 핵심 기본 클래스 라이브러리 디렉터리는 시스템의 Lib 디렉터리에 있습니다. 또한 확장 기본 클래스 라이브러리는 Extend/Library 디렉터리에 있으며 ORG 및 Com 확장 클래스 라이브러리를 확장할 수 있습니다. . 핵심 기본 클래스 라이브러리의 역할은 다음을 포함하여 프레임워크의 보편적인 개발을 완료하는 데 필요한 기본 클래스와 내장 지원 클래스를 완성하는 것입니다.

핵심 클래스 라이브러리 패키지에는 다음과 같은 핵심 클래스 라이브러리가 포함되어 있습니다.

类名	说明
Action	系统基础控制器类
App	系统应用类
Behavior	系统行为基础类
Cache	系统缓存类
Db	系统抽象数据库类
Dispatcher	URL调度类
Log	系统日志类
Model	系统基础模型类
Think	系统入口和静态类
ThinkException	系统基础异常类
View	视图类
Widget	系统Widget基础类

애플리케이션 클래스 라이브러리

애플리케이션 클래스 라이브러리는 프로젝트에서 정의되거나 사용되는 클래스 라이브러리를 의미합니다. 클래스 라이브러리 또한 ThinkPHP의 명명 규칙을 따릅니다. 애플리케이션 라이브러리 디렉터리는 프로젝트 디렉터리 아래의 Lib 디렉터리에 있습니다. 애플리케이션 라이브러리에는 액션 라이브러리, 모델 라이브러리 또는 기타 도구 라이브러리를 포함하여 일반적으로 다음과 같은 광범위한 범위가 있습니다.

目录	调用路径	说明
Lib/Action	@.Action或自动加载	控制器类库包
Lib/Model	@.Model或自动加载	模型类库包
Lib/Behavior	用B方法调用或自动加载	应用行为类库包
Lib/Widget	用W方法在模板中调用	应用Widget类库包

项目根据自己的需要可以在项目类库目录下面添加自己的类库包，例如Lib/Common、Lib/Tool等。

类库导入

一、Import显式导入

ThinkPHP模拟了Java的类库导入机制，统一采用import方法进行类文件的加载。import方法是ThinkPHP内建的类库导入方法，提供了方便和灵活的文件导入机制，完全可以替代PHP的require和include方法。例如：

import("Think.Util.Session");
 import("App.Model.UserModel");

로그인 후 복사

import方法具有缓存和检测机制，相同的文件不会重复导入，如果导入了不同的位置下面的同名类库文件，系统也不会再次导入

注意：在Unix或者Linux主机下面是区别大小写的，所以在使用import方法的时候要注意目录名和类库名称的大小写，否则会导入失败。对于import方法，系统会自动识别导入类库文件的位置，ThinkPHP的约定是Think、ORG、Com包的导入作为基类库导入，否则就认为是项目应用类库导入。

import("Think.Util.Session");
 import("ORG.Util.Page");

로그인 후 복사

上面两个方法分别导入了Think基类库的Util/Session.class.php文件和ORG扩展类库包的Util/Page.class.php文件。

要导入项目的应用类库文件也很简单，使用下面的方式就可以了，和导入基类库的方式看起来差不多：

import("MyApp.Action.UserAction");
 import("MyApp.Model.InfoModel");

로그인 후 복사

上面的方式分别表示导入MyApp项目下面的Lib/Action/UserAction.class.php和Lib/Model/InfoModel.class.php类文件。

通常我们都是在当前项目里面导入所需的类库文件，所以，我们可以使用下面的方式来简化代码

import("@.Action.UserAction");
 import("@.Model.InfoModel");

로그인 후 복사

二，别名导入

除了命名空间的导入方式外，import方法还可以支持别名导入，要使用别名导入，首先要定义别名，我们可以在项目配置目录下面增加alias.php 用以定义项目中需要用到的类库别名，例如：

return array(
    &#39;rbac&#39; =>LIB_PATH.&#39;Common/Rbac.class.php&#39;,
    &#39;page&#39; =>LIB_PATH.&#39;Common/Page.class.php&#39;,
 );

로그인 후 복사

那么，现在就可以直接使用：

```
import("rbac");
 import("page");
```
로그인 후 복사

导入Rbac和Page类，别名导入方式禁止使用import方法的第二和第三个参数，别名导入方式的效率比命名空间导入方式要高效，缺点是需要预先定义相关别名。

导入第三方类库

第三方类库统一放置在系统扩展目录下的Vendor 目录，并且使用vendor 方法导入，其参数和 import 方法是一致的，只是默认的值有针对变化。例如，我们把 Zend 的 Filter\Dir.php 放到 Vendor 目录下面，这个时候 Dir 文件的路径就是 Vendor\Zend\Filter\Dir.php，我们使用vendor 方法导入只需要使用：

```
Vendor(&#39;Zend.Filter.Dir&#39;);
```
로그인 후 복사

就可以导入Dir类库了。
Vendor方法也可以支持和import方法一样的基础路径和文件名后缀参数，例如：

Vendor(&#39;Zend.Filter.Dir&#39;,dirname(__FILE__),&#39;.class.php&#39;);

로그인 후 복사

自动加载

在大多数情况下，我们无需手动导入类库，而是通过配置采用自动加载机制即可，自动加载机制是真正的按需加载，可以很大程度的提高性能。自动加载有三种情况，按照加载优先级从高到低分别是：别名自动加载、系统规则自动加载和自定义路径自动加载。

一、别名自动加载

在前面我们提到了别名的定义方式，并且采用了import方法进行别名导入，其实所有定义别名的类库都无需再手动加载，系统会按需自动加载。

二、系统规则自动加载

果你没有定义别名的话，系统会首先按照内置的规则来判断加载，系统规则仅针对行为类、模型类和控制器类，搜索规则如下：

类名	规则	说明
行为类	规则1	搜索系统类库目录下面的Behavior目录
	规则2	搜索系统扩展目录下面的Behavior目录
	规则3	搜索应用类库目录下面的Behavior目录
	规则4	如果启用了模式扩展，则搜索模式扩展目录下面的Behavior目录
模型类	规则1	如果启用分组，则搜索应用类库目录的Model/当前分组目录
	规则2	搜索应用类库下面的Model目录
	规则3	搜索系统扩展目录下面的Model目录
控制器类	规则1	如果启用分组，则搜索应用类库目录的Action/当前分组目录
	规则2	搜索项目类库目录下面的Action目录
	规则3	搜索系统扩展目录下面的Action目录

注意：搜索的优先顺序从上至下，一旦找到则返回，后面规则不再检测。如果全部规则检测完成后依然没有找到类库，则开始进行第三个自定义路径自动加载检测。

三、自定义路径自动加载

当你的类库比较集中在某个目录下面，而且不想定义太多的别名导入的话，可以使用自定义路径自动加载方式，这种方式需要在项目配置文件中添加自动加载的搜索路径，例如：

&#39;APP_AUTOLOAD_PATH&#39; =>&#39;@.Common,@.Tool&#39;,

로그인 후 복사

表示，在当前项目类库目录下面的Common和Tool目录下面的类库可以自动加载。多个搜索路径之间用逗号分割，并且注意定义的顺序也就是自动搜索的顺序。

注意：自动搜索路径定义只能采用命名空间方式，也就是说这种方式只能自动加载项目类库目录和基类库目录下面的类库文件。

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

控制器：

1. URL模式

传统方式的文件入口访问会变成由URL的参数来统一解析和调度。

ThinkPHP支持四种URL模式，可以通过设置URL_MODEL参数来定义，包括普通模式、PATHINFO、REWRITE和兼容模式。

一、普通模式：设置URL_MODEL 为0
采用传统的URL参数模式

http://serverName/appName/?m=module&a=action&id=1

二、PATHINFO模式（默认模式）：设置URL_MODEL 为1
默认情况使用PATHINFO模式，ThinkPHP内置强大的PATHINFO支持，提供灵活和友好URL支持。PATHINFO模式自动识别模块和操作，例如

http://serverName/appName/module/action/id/1/或者
http://serverName/appName/module,action,id,1/

로그인 후 복사

三、REWRITE模式：设置URL_MODEL 为2
该URL模式和PATHINFO模式功能一样，除了可以不需要在URL里面写入口文件，和可以定义.htaccess 文件外。在开启了Apache的URL_REWRITE模块后，就可以启用REWRITE模式了，具体参考下面的URL重写部分。

四、兼容模式：设置URL_MODEL 为3
兼容模式是普通模式和PATHINFO模式的结合，并且可以让应用在需要的时候直接切换到PATHINFO模式而不需要更改模板和程序，还可以和URL_WRITE模式整合。兼容模式URL可以支持任何的运行环境。

兼容模式的效果是：

http://serverName/appName/?s=/module/action/id/1/

并且也可以支持参数分割符号的定义，例如在URL_PATHINFO_DEPR为~的情况下，下面的URL有效：

http://serverName/appName/?s=module~action~id~1

其实是利用了VAR_PATHINFO参数，用普通模式的实现模拟了PATHINFO的模式。但是兼容模式并不需要自己传s变量，而是由系统自动完成URL部分。正是由于这个特性，兼容模式可以和PATHINFO模式之间直接切换，而不需更改模板文件里面的URL地址连接。我们建议的方式是采用PATHINFO模式开发，如果部署的时候环境不支持PATHINFO则改成兼容URL模式部署即可，程序和模板都不需要做任何改动。

2. 模块和操作

http://域名/项目名/分组名/模块名/操作名/其他参数
Dispatcher会根据URL地址来获取当前需要执行的项目、分组（如果有定义的话）模块、操作以及其他参数，在某些情况下，项目名可能不会出现在URL地址中（通常情况下入口文件则代表了某个项目，而且入口文件可以被隐藏）。
每一个模块就是一个控制器类，通常位于项目的Lib\Action目录下面。

3.1版本开始，增加ACTION_SUFFIX配置参数，用于设置操作方法的后缀。
例如，如果设置：

'ACTION_SUFFIX'=>'Act'

那么访问某个模块的add操作对应读取模块类的操作方法则由原来的add方法变成addAct方法。

3. 定义控制器和空操作，空模块

一个应用如果不需要和数据库交互的时候可以不需要定义模型类，但是必须定义Action控制器，一般位于项目的Lib/Action目录下面。
Action控制器的定义非常简单，只要继承Action基础类就可以了，例如：

Class UserAction extends Action{}

控制器文件的名称是UserAction.class.php。

빈 작업은 시스템이 지정된 작업 메서드를 찾을 수 없을 때 실행할 빈 작업(_empty) 메서드를 찾는다는 의미입니다. 이 메커니즘을 사용하면 오류 페이지와 일부 URL의 최적화를 실현할 수 있습니다.

빈 모듈의 개념은 시스템이 지정된 모듈 이름을 찾을 수 없을 때 시스템이 빈 모듈(EmptyAction)을 찾으려고 시도한다는 의미입니다. 이 메커니즘을 사용하여 오류 페이지와 URL을 사용자 정의할 수 있습니다. 최적화.

4. 모듈 그룹화

모듈 그룹화와 관련된 구성 매개변수는 다음과 같습니다.

配置参数	说明
APP_GROUP_LIST	项目分组列表（配置即表示开启分组）
DEFAULT_GROUP	默认分组（默认值为Home）
TMPL_FILE_DEPR	分组模板下面模块和操作的分隔符，默认值为“/”
VAR_GROUP	分组的URL参数名，默认为g（普通模式URL才需要）

예를 들어 현재 프로젝트를 각각 프런트엔드 기능과 백엔드 기능을 나타내는 Home과 Admin의 두 그룹으로 나누면 프로젝트 구성에 다음 구성만 추가하면 됩니다.

'APP_GROUP_LIST' => '홈,관리자', //프로젝트 그룹 설정
'DEFAULT_GROUP' => 그룹

여러 그룹은 쉼표로 구분할 수 있으며 기본적으로 하나의 그룹만 설정할 수 있습니다.

5. URL 의사 정적

ThinkPHP는 의사 정적 URL 설정을 지원하며, URL_HTML_SUFFIX 매개변수를 설정할 수 있습니다. 현재 작업의 정상적인 실행에 영향을 주지 않고 끝에 원하는 정적 접미사를 추가합니다. 예를 들어

'URL_HTML_SUFFIX'=>'shtml'

을 설정하면 다음 URL을

<으로 설정할 수 있습니다. 🎜 >

http://serverName/Blog/read/id/1

은

http://가 됩니다. serverName/Blog/read/id/1.shtml

후자는 정적 페이지의 URL 특성을 가지지만 이전 URL과 동일한 실행 효과를 가지며 원본에는 영향을 주지 않습니다. 사용 매개변수.

참고: 의사 정적 접미사는 설정할 때 접미사에 "."를 포함할 필요가 없습니다. 따라서 다음 구성은 실제로 동일합니다.

'URL_HTML_SUFFIX'=>'.shtml'

Pseudo-static 설정 후, 일관된 URL을 동적으로 생성해야 하는 경우 U 메서드를 사용하여 템플릿 파일에서 URL을 생성할 수 있습니다.

버전 3.1부터 기본적으로 모든 정적 접미사를 지원할 수 있으며 현재 의사 정적 접미사를 상수 __EXT__에 기록하지만 정상적인 페이지 액세스에는 영향을 미치지 않습니다. 현재 의사 정적 접미사를 얻으려면 상수 __EXT__를 통해 얻으십시오.

구성된 의사 정적 접미사만 지원하려는 경우 여러 접미사를 지원하도록 직접 설정할 수 있습니다. 예:

'URL_HTML_SUFFIX'=> 'html|shmtl | 첫 번째 접미사는 기본적으로 사용되며 URL 주소를 생성하기 위한 접미사 지정도 지원합니다.

6. URL 라우팅

ThinkPHP는 URL 라우팅 기능을 지원하려면 URL_ROUTER_ON 매개변수를 true로 설정해야 합니다. . 라우팅 기능이 활성화되고 URL_ROUTE_RULES 매개변수가 구성된 후 시스템은 현재 URL과 일치하는 경로 이름이 경로 정의에서 발견되면 경로 분석 및 리디렉션이 수행됩니다.

자세한 내용은 http://doc.thinkphp.cn/manual/url_route.html을 참조하세요.

URL 재작성

자세한 내용은 http://doc.thinkphp.cn/manual/url_rewrite.html을 참조하세요.

<code><code><code><code><code><code><code><code><code>8. URL 생성<code><code><code><code><code><code> <code> <code><code><code>사용된 URL 모드를 일치시키기 위해서는 현재 URL 설정을 기반으로 해당 URL 주소를 동적으로 생성할 수 있어야 합니다. URL의 동적 생성을 위한 U 방법. 이는 마이그레이션 프로세스 중에 프로젝트가 환경의 영향을 받지 않도록 합니다. U 방식의 정의 규칙은 다음과 같습니다(대괄호 안의 매개변수는 실제 적용에 따라 결정됨).

<code><code><code><code><code><code><code><code><code>为了配合所使用的URL模式，我们需要能够动态的根据当前的URL设置生成对应的URL地址，为此，ThinkPHP内置提供了U方法，用于URL的动态生成，可以确保项目在移植过程中不受环境的影响。 U方法的定义规则如下（方括号内参数根据实际应用决定）： U('[그룹/모듈/작업]?Parameter' [,'Parameter','의사 정적 접미사 ','점프 여부','도메인 이름 표시'])

 프로젝트와 모듈이 정의되지 않은 경우 현재 프로젝트와 모듈 이름을 나타냅니다. 다음은 몇 가지 간단한 예입니다. 
<code><code><code><code><code><code><code><code><code>如果不定义项目和模块的话 就表示当前项目和模块名称，下面是一些简单的例子：U('User/add') // URL 주소 생성 사용자 모듈의 추가 작업 
U('Blog/read?id=1') // 블로그 모듈의 읽기 작업과 ID가 1인 URL 주소를 생성합니다
U('Admin/User/select') // Admin 그룹의 User 모듈 선택 작업의 URL 주소를 생성합니다. 
  U 메소드의 두 번째 매개변수는 배열과 배열이라는 두 가지 정의 메소드를 지원합니다. 문자열 매개변수인 경우 첫 번째 매개변수에 정의할 수 있습니다. 예: U( 'Blog/cate',array('cate_id'=>1,'status'=>1))
U('블로그/cate','cate_id=1&status= 1')
<code><code><code><code><code><code><code><code><code>U方法的第二个参数支持数组和字符串两种定义方式，如果只是字符串方式的参数可以在第一个参数中定义，例如：U('블로그/cate?cate_id=1&status= 1')
<code><code><code><code><code><code><code><code><code>三种方式是等效的，都是 生成Blog模块的cate操作 并且cate_id为1 status为1的URL地址
但是不允许使用下面的定义方式来传参数
U('Blog/cate/cate_id/1/status/1')
<code><code><code><code><code><code><code><code><code>
根据项目的不同URL设置，同样的U方法调用可以智能地对应产生不同的URL地址效果，例如针对
U（'Blog/read?id=1'）这个定义为例。
如果当前URL设置为普通模式的话，最后生成的URL地址是： 
http://serverName/index.php?m=Blog&a=read&id=1
如果当前URL设置为PATHINFO模式的话，同样的方法最后生成的URL地址是： 
http://serverName/index.php/Blog/read/id/1
如果当前URL设置为REWRITE模式的话，同样的方法最后生成的URL地址是： 
http://serverName/Blog/read/id/1
如果当前URL设置为REWRITE模式，并且设置了伪静态后缀为.html的话，同样的方法最后生成的URL地址是： 
http://serverName/Blog/read/id/1.html
U方法还可以支持路由，如果我们定义了一个路由规则为：
 'news/:id\d'=>'News/read'
那么可以使用
U（'/news/1'）
最终生成的URL地址是：
http://serverName/index.php/news/1

注意：如果你是在模板文件中直接使用U方法的话，需要采用 {:U('参数1', '参数2'…)} 的方式，具体参考模板引擎章节的8.3 使用函数内容。
如果你的应用涉及到多个子域名的操作地址，那么也可以在U方法里面指定需要生成地址的域名，例如：
U('Blog/read@blog.thinkphp.cn','id=1');
@后面传入需要指定的域名即可。
此外，U方法的第5个参数如果设置为true，表示自动识别当前的域名，并且会自动根据子域名部署设置APP_SUB_DOMAIN_DEPLOY和APP_SUB_DOMAIN_RULES自动匹配生成当前地址的子域名。
如果开启了URL_CASE_INSENSITIVE，则会统一生成小写的URL地址。
9. URL大小写
只要在项目配置中，增加：
'URL_CASE_INSENSITIVE' =>true
就可以实现URL访问不再区分大小写了。
这里需要注意一个地方，如果我们定义了一个UserTypeAction的模块类，那么URL的访问应该是：
http://serverName/index.php/user_type/list
 //而不是
http://serverName/index.php/usertype/list
利用系统提供的U方法可以为你自动生成相关的URL地址。
如果设置
'URL_CASE_INSENSITIVE' =>false
的话，URL就又变成：
http://serverName/index.php/UserType/list
注意：URL不区分大小写并不会改变系统的命名规范，并且只有按照系统的命名规范后才能正确的实现URL不区分大小写。
10. 前置和后置操作
系统会检测当前操作是否具有前置和后置操作，如果存在就会按照顺序执行，前置和后置操作的方法名是在要执行的方法前面加 _before_和_after_，例如：
class CityAction extends Action{
    //前置操作方法
    public function _before_index(){
        echo &#39;before&#39;;
    }
    public function index(){
        echo &#39;index&#39;;
    }
    //后置操作方法
    public function _after_index(){
        echo &#39;after&#39;;
    }
 }
로그인 후 복사
对于任何操作方法我们都可以按照这样的规则来定义前置和后置方法。
<code><code><code><code><code><code><code><code><code>
如果当前的操作并没有定义操作方法，而是直接渲染模板文件，那么如果定义了前置 和后置方法的话，依然会生效。真正有模板输出的可能仅仅是当前的操作，前置和后置操作一般情况是没有任何输出的。
需要注意的是，在有些方法里面使用了exit或者错误输出之类的话 有可能不会再执行后置方法了。
例如，如果在当前操作里面调用了系统Action的error方法，那么将不会再执行后置操作，但是不影响success方法的后置方法执行。
<code><code><code><code><code><code><code><code><code>

11. 跨模块调用
<code>例如，我们在Index模块调用User模块的操作方法
class IndexAction extends Action{
    public function index(){
        //实例化UserAction
        $User = new UserAction();
        //其他用户操作
         //...
        $this->display(); //输出页面模板
    }
 }
로그인 후 복사
因为系统会自动加载Action控制器，因此 我们不需要导入UserAction类就可以直接实例化。
并且为了方便跨模块调用，系统内置了A方法和R方法。    $User = A('User');
<code>事实上，A方法还支持跨分组或者跨项目调用，默认情况下是调用当前项目下面的模块。<br/>跨项目调用的格式是：<br/>A(&#39;[项目名://][分组名/]模块名&#39;)<br/>例如：
A(&#39;User&#39;) //表示调用当前项目的User模块
A(&#39;Admin://User&#39;) //表示调用Admin项目的User模块
A(&#39;Admin/User&#39;) //表示调用Admin分组的User模块
A(&#39;Admin://Tool/User&#39;) //表示调用Admin项目Tool分组的User模块
로그인 후 복사

R方法表示调用一个模块的某个操作方法，调用格式是：
R('[项目名://][分组名/]模块名/操作名',array('参数1','参数2'…))
例如：
R(&#39;User/info&#39;) //表示调用当前项目的User模块的info操作方法
R(&#39;Admin/User/info&#39;) //表示调用Admin分组的User模块的info操作方法
R(&#39;Admin://Tool/User/info&#39;) //表示调用Admin项目Tool分组的User模块的info操作方法
로그인 후 복사
R方法还支持对调用的操作方法需要传入参数，例如User模块中我们定义了一个info方法：
class UserAction extends Action{
    protected function info($id){
        $User = M(&#39;User&#39;);
        $User->find($id);
        //...
    }
 }
로그인 후 복사
接下来，我们可以在其他模块中调用：
R('User/info',array(15))
表示调用当前项目的User模块的info操作方法，并且id参数传入15


12. 页面跳转
<code><code>系统的Action类内置了两个跳转方法success和error，用于页面跳转提示，而且可以支持ajax提交。使用方法很简单，举例如下：
$User = M(&#39;User&#39;); //实例化User对象
$result = $User->add($data); 
if($result){
    //设置成功后跳转页面的地址，默认的返回页面是$_SERVER[&#39;HTTP_REFERER&#39;]
    $this->success(&#39;新增成功&#39;, &#39;User/list&#39;);
} else {
    //错误页面的默认跳转页面是返回前一页，通常不需要设置
    $this->error(&#39;新增失败&#39;);
}
로그인 후 복사
Success和error方法都有对应的模板，并且是可以设置的，默认的设置是两个方法对应的模板都是：
//默认错误跳转对应的模板文件
&#39;TMPL_ACTION_ERROR&#39; => THINK_PATH . &#39;Tpl/dispatch_jump.tpl&#39;;
//默认成功跳转对应的模板文件
&#39;TMPL_ACTION_SUCCESS&#39; => THINK_PATH . &#39;Tpl/dispatch_jump.tpl&#39;;
로그인 후 복사
也可以使用项目内部的模板文件
//默认错误跳转对应的模板文件
&#39;TMPL_ACTION_ERROR&#39; => &#39;Public:error&#39;;
//默认成功跳转对应的模板文件
&#39;TMPL_ACTION_SUCCESS&#39; => &#39;Public:success&#39;;
로그인 후 복사
模板文件可以使用模板标签，并且可以使用下面的模板变量：
$msgTitle 操作标题
$message 页面提示信息
$status 操作状态 1表示成功 0 表示失败 具体还可以由项目本身定义规则
$waitSecond 跳转等待时间 单位为秒
$jumpUrl 跳转页面地址
success和error方法会自动判断当前请求是否属于Ajax请求，如果属于Ajax请求则会调用ajaxReturn方法返回信息，具体可以参考后面的AJAX返回部分。

3.1版本开始，error和success方法支持传值，无论是跳转模板方式还是ajax方式 都可以使用assign方式传参。例如：
$this->assign(&#39;var1&#39;,&#39;value1&#39;);
$this->assign(&#39;var2&#39;,&#39;value2&#39;);
$this->error(&#39;错误的参数&#39;,&#39;要跳转的URL地址&#39;);
로그인 후 복사
当正常方式提交的时候，var1和var2变量会赋值到错误模板的模板变量。
当采用AJAX方式提交的时候，会自动调用ajaxReturn方法传值过去（包括跳转的URL地址url和状态值status）


13. 重定向
Action类的redirect方法可以实现页面的重定向功能。
redirect方法的参数用法和U函数的用法一致（参考上面的URL生成部分），例如：
//重定向到New模块的Category操作
$this->redirect(&#39;New/category&#39;, array(&#39;cate_id&#39; => 2), 5, &#39;页面跳转中...&#39;);
로그인 후 복사
上面的用法是停留5秒后跳转到News模块的category操作，并且显示页面跳转中字样，重定向后会改变当前的URL地址。
如果你仅仅是想重定向要一个指定的URL地址，而不是到某个模块的操作方法，可以直接使用redirect方法重定向，例如：

//重定向到指定的URL地址
redirect('/New/category/cate_id/2', 5, '页面跳转中...')

Redirect方法的第一个参数是一个URL地址。


14. 获取系统变量
$this->方法名("变量名",["过滤方法"],["默认值"])
<code><code><code>方法名可以支持：



方法名
含义


_get
获取GET参数


_post
获取POST参数


_param
自动判断请求类型获取GET、POST或者PUT参数（3.1新增）


_request
获取REQUEST 参数


_put
获取PUT 参数


_session
获取 $_SESSION 参数








以上就是ThinkPHP- 31的内容，更多相关内容请关注PHP中文网（www.php.cn）！

$msgTitle	操作标题
$message	页面提示信息
$status	操作状态 1表示成功 0 表示失败具体还可以由项目本身定义规则
$waitSecond	跳转等待时间单位为秒
$jumpUrl	跳转页面地址

方法名	含义
_get	获取GET参数
_post	获取POST参数
_param	自动判断请求类型获取GET、POST或者PUT参数（3.1新增）
_request	获取REQUEST 参数
_put	获取PUT 参数
_session	获取 $_SESSION 参数

ThinkPHP-31

一、Import显式导入

二，别名导入

一、别名自动加载

二、 系统规则自动加载

三、 自定义路径自动加载

二、系统规则自动加载

三、自定义路径自动加载