RAD 프레임워크의 엔지니어링 내부... Nooku의 PHP 개발자

모든 사람은 자신만의 도구 세트를 가지고 있습니다. PHP 개발자로서 제가 가장 좋아하는 것 중 하나는 "Nooku"라는 Rapid Application Development 프레임워크입니다. 개발 그룹의 말: "Nooku는 프레임워크라기보다 웹 개발 툴킷에 가깝습니다."

익숙하지 않은 경우 살펴보십시오. 쉽게 확장하고 재사용할 수 있는 고도로 구성 요소화된 애플리케이션을 생성하기 위해 업계에서 인정하는 디자인 패턴을 많이 사용하는 오픈 소스 프로젝트입니다(초기에는 선도적인 Joomla! 개발자 중 한 명이 만들었습니다). 기본적으로 Nooku는 프로젝트를 더 빨리 시작하는 데 도움이 되는 많은 신속한 애플리케이션 개발 도구를 제공합니다. 작지만 강력한 샘플:

• 레이아웃을 작성하기만 하면 되는 MVC의 기본 구현(이것이 바로 나를 사로잡은 것입니다)
• HMVC 즉시 사용 가능
• 모든 데이터에 대해 JSON 및 XML과 같은 다양한 출력 형식 지원(예: 몇 분 안에 API 노출)
• 기본 관리 및 프런트 엔드 구현

Nooku의 핵심은 "상속보다 구성" 디자인 원칙입니다(사실, 이것은 Nooku 소개 페이지의 첫 번째 개념입니다. 한 줄로: 여러 객체의 기능을 구성(또는 합산)하여 일부를 생성하는 것을 목표로 해야 합니다. 서브클래싱에 의존하지 않고 일종의 복합 객체입니다.

이 원칙을 사용하면 코드를 덜 작성할 수 있고 종종 꽤 우아한 솔루션을 얻을 수 있습니다. 그렇다면 구체적으로 어떻게 추진되고 있습니까? 글쎄요, 코드 수준에서 가장 좋은 예는 믹스인과 리소스/서비스 식별자를 사용하는 것입니다. 한 번 보자.

믹신

PHP 5.4 이전에는 언어에 Traits 개념이 없었습니다. 이들은 객체에 의해 '사용'될 때 어떤 유형의 기능(다중 상속과 유사)을 제공하는 클래스와 유사한 구조입니다. Nooku는 (PHP 5.2부터) 이 문제를 Mixin 으로 해결해 왔습니다.

Mixin을 사용하면 개체를 함께 구성할 수 있을 뿐만 아니라 각 혼합 개체의 메서드를 합성 개체의 인터페이스에 추가할 수 있습니다. mixin을 사용하는 개체는 개체의 메서드에서 혼합된 메서드를 '상속'하는 것 같습니다.

 /** * Mixin an object * * When using mixin(), the calling object inherits the methods of the mixed * in objects, in a LIFO order. * * @param KMixinInterface $object An object that implements KMinxInterface * @return KObject */ public function mixin(KMixinInterface $object) { $methods = $object->getMixableMethods($this); foreach($methods as $method) { $this->_mixed_methods[$method] = $object; } // Set the mixer $object->setMixer($this); return $this; }

Nooku의 거의 모든 개체에는 mixin 메서드를 정의한 기본 클래스 KObject를 확장하기 때문에 이 기능이 있습니다.

Nooku 컨트롤러 아키텍처의 주요 클래스도 KObject의 후손입니다. 추상 컨트롤러는 KControllerAbstract 클래스이며 검사를 통해 Mixing 기능을 즉시 활용하는 것을 볼 수 있습니다. 이 클래스의 인스턴스가 생성될 때마다 KMixinCommand 및 KMixinBehavior 기능이 해당 인터페이스에 즉시 추가됩니다. 따라서 Nooku의 각 컨트롤러는 해당 개체를 통해 Command Chain 및 Behavior 관리 기능으로 구성됩니다.

Nooku 컨트롤러로 돌아가기: KMixinBehavior 클래스는 KControllerAbstract에 런타임에 특정 동작 을 로드할 수 있는 기능을 제공하는 모든 부분을 보유합니다. 행동 전략은 다른 클래스(예: 편집 가능, 주문 가능)에서 분리 및 사용할 수 있는 프로세스 또는 논리를 설명하는 클래스입니다. KMixinBehavior는 매우 간단하며 getBehavior, hasBehavior, addBehavior 및 getBehaviors의 네 가지 메서드만 있습니다. 그리고 그것이 우리가 객체에 다양한 행동 전략을 처리하고 캡슐화할 수 있는 능력을 부여하는 데 필요한 전부입니다.

마찬가지로 KMixinCommand에는 getCommandContext, getCommandChain, setCommandChain의 세 가지 메서드만 있습니다. 추측하지 못했다면 이 세 가지 방법은 KControllerAbstract에 명령 체인을 구현하는 기능을 제공하지만 런타임에 그렇게 할 수 있도록 합니다.

이 혼합을 간단한 산술 덧셈으로 생각할 수 있습니다.

다음과 같은 인터페이스를 제공합니다.

정의에 따르면 추상 클래스는 확장을 의미하므로 KControllerAbstract의 자식 또는 인스턴스인 모든 개체는 상속의 마법에 의해 런타임에 동작과 명령 체인을 추가하는 기능도 얻습니다.

멋진데. 그러나 그것은 실제로 무엇을 의미합니까? 간단히 말해서 Nooku는 구성 요소화된 기능을 제공합니다. 즉, Nooku를 사용하면 기능을 모듈화하고 런타임에 여러 모듈에서 기능을 구성할 수 있습니다.

이 두 가지 예는 구성을 보여줍니다. 또한 핵심에서 추가 구성에 대한 Nooku RAD 프레임워크의 지원을 입증하는 역할도 합니다. 이것은 중요한 이점입니다. 위의 KControllerAbstract에 추가된 메서드는 개발자에게 한 줄의 코드가 작성되기 전에 달라지는 것을 캡슐화하는 도구를 제공하여 "전략 디자인 패턴"을 지원합니다. mixin() 메서드가 KObject의 모든 확장의 일부라는 사실은 런타임에 다른 행동 관리 인터페이스를 쉽게 정의하고 대부분의 개체에 추가할 수 있음을 의미합니다.

서비스 및 리소스 식별자 및 로케이터: 내 개체에서 내 클래스 이름 분리

Nooku의 서비스 및 리소스 식별자와 로케이터는 또한 관심사 분리를 위한 강력한 지원을 제공합니다.

다시 KObject뿐만 아니라 KService도 살펴보겠습니다. 우리는 Nooku에서 대부분의 것을 서비스나 리소스로 취급할 수 있으며, 정확히 같은 방식으로 인스턴스화하고 질문할 수 있습니다.

식료품점에 가서 제품을 구매할 때 상점을 서비스라고 생각하십시오. 리소스로서의 제품, 즉 다음과 같은 단일 항목/솔루션 로직:

• 구체적으로 살펴보다( 읽기 ) (예: 토마토 수프 캔을 바라보며)
• 가게를 돌아다니다( E 편집됨) (예: 수프를 농산물 통로로 옮김)
• 상점 인벤토리에 추가 또는 제거( 추가 및 삭제 )(예: 새로운 종류 의 수프를 추가하고 토마토를 제거)

이 예에서 더 나아가 식료품점에 프랜차이즈 부서가 있고 사업을 하고 싶어한다고 상상해 보십시오. 이 상황에서 서비스는 프랜차이즈 부서이고 리소스는 구매하는 식료품점입니다. 그것은 매우 맥락적인 분류입니다. 전체적으로 이것은 BREAD 액션 패턴으로 알려져 있습니다(KControllerService와 KControllerResource 사이에 '_action', 즉 _actionRead()이 붙은 각 패턴을 볼 수 있습니다).

모델은 서비스가 될 수 있고, 테이블 개체는 서비스로 생각할 수 있으며, 특정 MVC 트라이어드는 리소스 또는 서비스로 인스턴스화되는 반면, 서비스를 조사한 결과 특정 레코드는 리소스로 생각할 수 있습니다.

Nooku의 모든 객체는 '서비스 컨테이너'에 있는 전체 애플리케이션의 인스턴스화된 서비스에 대한 참조와 getService()라는 서비스에 액세스하는 메서드를 포함한다는 점에서 객체의 구성입니다. KObject::getService() 메서드에 필요한 것은 유효한 리소스 식별자를 전달하고 사용할 준비가 된 인스턴스화된 서비스를 반환하는 것입니다.

PHP의 신속한 애플리케이션 개발에서 리소스 식별자는 클래스 이름에서 개체의 인스턴스화를 분리하는 강력한 방법을 제공하므로 해당 식별에 대한 별칭을 제공합니다. 이것은 응용 프로그램의 유지 관리 가능성에 중요한 의미를 갖습니다. 앨리어싱을 통해 개발자는 KService::addAlias()로 한 줄의 코드를 추가하여 주어진 식별자로 인스턴스화되는 모든 객체에서 사용하는 클래스를 변경할 수 있습니다.

우리에게 익숙한 리소스 식별자의 예는 URI 또는 ​​Uniform Resource Identifier입니다.

이것은 KService가 적절한 클래스를 찾고 로드하는 데 필요한 모든 정보입니다. 이러한 조각은 배치 및 인스턴스화의 예측 가능성을 제공하는 Nooku의 클래스 명명 및 배치 규칙과 일치합니다. 위의 식별자 예제(com://site/user.database.table.user)는 클래스 이름이 ComUserDatabaseTableUser인 /components/com_user/databases/tables/user.php 파일을 로드하려고 시도합니다. 덧붙여서, 파일이 존재하지 않으면 프레임워크는 기본 테이블 개체를 제공하고 데이터베이스 명명 및 ID 스키마 규칙을 기반으로 빌드합니다(이것이 좀 더 매료되었습니다). 앞서 언급했듯이 KService를 사용하면 식별자에 대한 별칭을 설정할 수도 있습니다. KService::setAlias('maindbaseadapter','com://admin/default.database.adapter.mysqli') 사용 ; KService::getService('maindbaseadapter') 를 사용하여 db 객체를 로드할 수 있습니다.

이것은 우리가 이야기한 분리를 제공하고 애플리케이션의 유지 관리 및 확장에 있어 현저한 이점을 제공합니다. 필요한 경우 '사이트' 및 '관리자' 이외의 응용 프로그램을 자유롭게 만들 수 있으며 여기에 설명된 식별자를 통해 다른 응용 프로그램에 있는 서비스를 쉽게 사용하여 우리 솔루션이 요구 사항을 충족할 수 있습니다. 다시 말하지만, 이것은 Nooku가 PHP 및 RAD 개발자와 팀에 단일 클래스 개체뿐만 아니라 전체 서비스 및 응용 프로그램의 구성에 대한 지원을 무료로 제공하는 방법의 또 다른 예입니다.

합산

상속보다 구성을 마음에 두고 있습니다. 추가 아말감을 지원하기 위해 존재하는 스마트하고 기존의 구성 및 구조; 여기에 설명된 식별자가 있는 무료 서비스 지향 아키텍처인 Nooku는 피어 PHP 개발 도구보다 훨씬 앞서서 강력한 RAD 프레임워크를 제공합니다.