나는이 기사, How to implement a front controller를 우연히 만났다. 이 기사는 콘트롤러를로드하는 더 좋은 방법은 아파치를 위해 설계된 것이므로 아파치에 맡기는 것이다.컨트롤러를로드하려면 PHP 프론트 로더를 사용하거나 .htaccess를 사용하는 것이 더 좋습니까?
그래서 몇 가지 질문이 ...
단일 진입 점을 사용하여 해당 문서의 차 이의 것 같다 :
... 당신은 페이지 컨트롤러의 수백이있을 때 무엇에 대한? 당신은 거대한 전환 명령 또는 아마도 배열에 위장 된 뭔가, XML 문서 또는 뭐든 결국. 모든 페이지 요청에 대해 PHP는 사용자가 수행하려고 시도하는 현재 요청과 관련이없는 많은 데이터를 다시로드해야합니다.
매우 약한 주장입니다. 첫째, 이것은 라우팅 메커니즘을 구현하는 끔찍한 방법입니다. 둘째, 애플리케이션이 측정 가능한 영향을 미치기 위해서는 애플리케이션이 상당히 복잡해야합니다. 애플리케이션이이 컴플렉스 인 경우 엔트리 포인트에서 발생하는 모든 성능이 나머지 애플리케이션의 실행에 비해 최소 일 가능성이 높습니다.
복잡한 웹 앱의 프런트 엔드를 처리하는 PHP 스크립트가 유지하기 어렵다면, .htaccess 파일이 어떻게 생겼는지 상상해보십시오!
마지막으로 bytecode cache으로 문제를 피할 수 있으므로 모든 요청에 대해 스크립트를로드하는 "문제"가 발생합니다.
어쩌면 그것의 맥주, 그러나 그 기사는 나에게 조금 이해가되지 않았다, 그것은 또한 "단어"를 따옴표로 많이 넣었다. 나는 거기에 언급 된 몇 가지 것에 동의하지 않습니다. 그것은 ...that this approach to implementing a Front Controller in PHP does alot (sic) to raise the learning curve required to become fluent with the framework라고합니다. 물론 나는 그게 사실이라고 생각하지만 강력하고 유연하며 큰 시스템을 가지고있을 때는 이 아니라에 약간의 학습이 필요합니다. 귀하의 질문에 관해서
:
.htaccess이 PHP를 사용하는 다소 실행 가능한 대안이 될 수 있지만, 신속하게 관리 할 훨씬 적은 확장하고 복잡해진다 하드입니다 수 있습니다. 아파치, lighttpd, nginx에서 이와 같이 URL 설정을 할 수 있으며, 가끔씩 수행하는 것을 보았습니다.하지만이 방법을 사용하면 큰 학습 곡선이됩니다.
PHP를 사용하여 라우팅을 수행하면 설정 파일, 배열 또는 객체를 통해 주입 된 경로 정보를 얻을 수 있습니다. 이렇게하면 많은 유연성을 얻을 수 있으며 여러 요소에 따라 경로를 포함하거나 제외 할 수 있습니다.
URL 구성을 위해 서버 구성 파일을 사용하면 다소 빠를 수 있지만 그 차이는 매우 작습니다. 서버 설정은 모듈화가 적어서 다른 HTTP 서버를 통해 이식 할 수 없습니다. 자국어 프론트 컨트롤러는 모든 서버 플랫폼에서 작동합니다.
MVC 프레임 워크를 보지 못했지만 PHP 이외의 많은 것을 조사하지 않았습니다.
도울 수 없습니다.
개인적으로 PHP에서는 Zend Framework을 많이 사용합니다. 하나의 스크립트를 통해 모든 것을 라우팅하는 전면 컨트롤러 패턴을 사용합니다. 나는이 방법에 아무런 제한을 두지 않았으며, 필요한 것 이상의 것을 제공합니다.
내 생각입니다. 도움이 되길 바랍니다.
나는 항상 라우트를 라우터 클래스로 전달한 다음 특정 라우트에 대한 특정 컨트롤러가로드되어 있거나로드되지 않은 경우 두 번째 라우터와 같은 기본/프런트 컨트롤러가로드됩니다. 플러그인 또는 페이지가 아닌 경우 404 ect를로드합니다. 이 방법은 각 경로/기능에 대한 새로운 컨트롤러를 만들지 않고도 쉽게 플러그인을 추가 할 수 있습니다. 실제로 스크립트를 확장하는 방법에 따라 달라집니다. –
그래, 이것이 대부분의 사람들이하는 것처럼 보입니다. .htaccess 프론트 로더 패러다임에서 .htaccess는 PHP 스크립트 대신 404와 다른 오류 페이지를 처리하게됩니다. 플러그인 등의로드는 추상 컨트롤러를 서브 클래 싱하여 수행 할 수 있습니다. – br3nt