php前端控制器2

Front Controllers act like centralized agents in an application whose primary area of concern is to dispatch commands, either statically or dynamically, to predefined handlers such as page controllers, REST resources, or pretty much anything else that comes to mind.

Building at least a naive front controller is a pretty instructional experience in understanding the nitty-gritty of them, and to promote this idea from a pragmatic standpoint, I went through the implementation of a contrived front controller in the introductory article which packaged all the logic required for routing and dispatching requests inside the boundaries of a single class.

One of the best things about front controllers is that you can keep them running as tight structures, just routing and dispatching incoming requests, or you can let your wild side show and implement a full-fledged完备的，成熟的 RESTful controller capable of parsing HTTP verbs, accommodating pre/post dispatch hooks, and the like, all behind a unified API. But while this approach is appealing, it breaks the Single Responsibility Principle (SRP) and goes against the nature of OOP itself which actively pushes the delegation of different tasks to several fine-grained objects.

So does this mean I’m just another sinful soul who dared to break from the commandments of the SRP? Well, in a sense I am. So I’d like to wash away my sins by showing you how easy is to deploy a small, yet extensible, HTTP framework capable of putting to work a front controller along with the ones of a standalone router and a dispatcher. Plus, the whole request/response cycle will be independently handled by a couple of reusable classes, which naturally you’ll be able to tweak at will.

With such a huge proliferation of HTTP frameworks available packaged with full-featured components, it seems absurd 荒谬的to implement from scratch a front controller that routes and dispatches requests through a few modular classes, even if these ones retain the essence of the SRP. In a humble attempt to avoid being judged for reinventing the wheel, some chunks of my custom implementation will be inspired by the nifty EPHPMVC library written by Lars Strojny.

Dissecting the Request/Route/Dispatch/Response Cycle

The first task we should tackle is defining a couple of classes charged with modeling the data and behavior of a typical HTTP request/response cycle. Here’s the first one, coupled to the interface that it implements:

<?php
namespace AcmeLibrary;

interface RequestInterface
{
    public function getUri();
    public function setParam($key, $value);
    public function getParam($key);
    public function getParams();
}

<?php
namespace AcmeLibrary;

class Request implements RequestInterface
{
    protected $uri;
    protected $params = array();
    
    public function __construct($uri, array $params = array()) {
        if (!filter_var($uri, FILTER_VALIDATE_URL)) {
            throw new InvalidArgumentException("The URI is invalid.");
        }
        $this->uri = $uri;
        $this->params = $params;
    }
    
    public function getUri() {
        return $this->uri;
    }
    
    public function setParam($key, $value) {
        $this->params[$key] = $value;
        return $this;
    }
    
    public function getParam($key) {
        if (!isset($this->params[$key])) {
            throw new InvalidArgumentException(
                "The request parameter with key '$key' is invalid."); 
        }
        return $this->params[$key];
    }
    
    public function getParams() {
        return $this->params;
    }
}

The Request class encapsulates an incoming URI along with an array of parameters and models an extremely skeletal HTTP request. For the sake of brevity, additional data members such as the set of methods associated to the request in question have been deliberately left outside of the picture. If you feel in the mood to drop them into the class, go ahead and do so.

Having a slim HTTP request wrapper living happily on its own is all well and fine sure, but ultimately useless if not coupled to the counterpart that mimics the data and behavior of a typical HTTP response. Let’s fix and build up this complementary component:

<?php
namespace AcmeLibrary;

interface ResponseInterface
{
    public function getVersion();
    public function addHeader($header);
    public function addHeaders(array $headers);
    public function getHeaders();
    public function send();
}

<?php
namespace AcmeLibrary;

class Response implements ResponseInterface
{
    const VERSION_11 = "HTTP/1.1";
    const VERSION_10 = "HTTP/1.0";
    
    protected $version;
    protected $headers = array();
    
    public function __construct($version = self::VERSION_11) {
        $this->version = $version;
    }
    
    public function getVersion() {
        return $this->version;
    }
    
    public function addHeader($header) {
        $this->headers[] = $header;
        return $this;
    }
    
    public function addHeaders(array $headers) {
        foreach ($headers as $header) {
            $this->addHeader($header);
        }
        return $this;
    }
    
    public function getHeaders() {
        return $this->headers;
    }
    
    public function send() {
        if (!headers_sent()) {
            foreach($this->headers as $header) {
                header("$this->version $header", true);
            }
        } 
    }
}

headers_sent() 函数检查 HTTP 标头是否已被发送以及在哪里被发送。

如果报头已发送，则返回 true，否则返回 false。

header('xxx',true/false) 第二个参数作用：

The optional replace parameter indicates whether the header should replace a previous similar header, or add a second header of the same type. By default it will replace, but if you pass in FALSE as the second argument you can force multiple headers of the same type. F

为true表示代替前面的header。默认为true.

The Response class is unquestionably a more active creature than its partner Request. It acts like a basic container which allows you to stack up HTTP headers at will and is capable of sending them out to the client too.

With these classes doing their thing in isolation, it’s time to tackle the next part in the construction of a front controller. In a typical implementation, the routing/dispatching processes are most of the time encapsulated inside the same method, which frankly speaking isn’t that bad at all. In this case, however, it’d be nice to break down the processes in question and delegate them to different classes. This way, things are balanced a little more in the equally of their responsibilities.

在典型的实现中，route和dispatch大多数时候写在一起。在我们的case中，我们会把他们分解，写在不同的类中。通过这种方式，

事情有点平衡了。

Here’s the batch of classes that get the routing module up and running:

<?php
namespace AcmeLibrary;

interface RouteInterface
{
    public function match(RequestInterface $request);
    public function createController();
}

<?php
namespace AcmeLibrary;

class Route implements RouteInterface
{
    protected $path;
    protected $controllerClass;

    public function __construct($path, $controllerClass) {
        if (!is_string($path) || empty($path)) {
            throw new InvalidArgumentException("The path is invalid.");
        }
        if (!class_exists($controllerClass)) {
            throw new InvalidArgumentException("The controller class is invalid.");
        }
        $this->path = $path;
        $this->controllerClass = $controllerClass;
    }
    
    public function match(RequestInterface $request) {
        return $this->path === $request->getUri();
    }
    
    public function createController() {
        return new $this->controllerClass;
    }
}

<?php
namespace AcmeLibrary;

interface RouterInterface
{
    public function addRoute(RouteInterface $route);
    public function addRoutes(array $routes);
    public function getRoutes();
    public function route(RequestInterface $request, ResponseInterface $response);
}

<?php
namespace AcmeLibrary;

class Router implements RouterInterface
{
    protected $routes = array();
    
    public function __construct(array $routes = array()) {
        if (!empty($routes)) {
            $this->addRoutes($routes);
        }
    }
    
    public function addRoute(RouteInterface $route) {
        $this->routes[] = $route;
        return $this;
    }
    
    public function addRoutes(array $routes) {
        foreach ($routes as $route) {
            $this->addRoute($route);
        }
        return $this;
    }
    
    public function getRoutes() {
        return $this->routes;
    }
    
    public function route(RequestInterface $request, ResponseInterface $response) {
        foreach ($this->routes as $route) {
            if ($route->match($request)) {
                return $route;
            }
        }
        $response->addHeader("404 Page Not Found")->send();
        throw new OutOfRangeException("No route matched the given URI.");
    }
}

php header 404

header("HTTP/1.1 404 Not Found");exit;  

或者：

header("status: 404 not found");

最好2个一起写。

header("HTTP/1.1 404 Not Found");
header("Status: 404 Not Found");
exit;

As one might expect, there’s a plethora of options to choose from when it comes to implementing a functional routing mechanism. The above, at least in my view, exposes both a pragmatic and straightforward solution. It defines an independent Route class that ties a path to a given action controller, and a simple router whose responsibility is limited to checking if a stored route matches the URI associated to a specific request object.

上面的写法，定义了一个独立的Route类来bind被给的控制器，一个简单Router用来检查存储的route是否匹配请求的url。

To get things finally sorted out, we would need to set up a swift dispatcher that can be put to work side by side with the previous classes. The below class does exactly that:

<?php
namespace AcmeLibrary;

interface DispatcherInterface
{
    public function dispatch(RouteInterface $route, RequestInterface $request, ResponseInterface $response);
}

<?php
namespace AcmeLibrary;

class Dispatcher implements DispatcherInterface
{
    public function dispatch(RouteInterface $route, RequestInterface $request, ResponseInterface $response) {
        $controller = $route->createController();
        $controller->execute($request, $response);
    }
}

Scanning the Dispatcher, you’ll notice two things about. First, it doesn’t carry any state. Second, it implicitly assumes that each action controller will run under the surface of an execute()method.

This can be refactored in favor of a slightly more flexible schema if you wish (the first thing that comes to my mind is tweaking the implementation of the Route class), but for the sake of simplicity I’ll keep the dispatcher untouched.

By now you’re probably wondering how and where to drop a front controller capable of bring all of the previous classes together. Don’t be anxious, as that’s next!

Implementing a Customizable Front Controller

We’ve reached the moment we’ve all been waiting for since the very beginning, implementing the long awaited front controller. But if you were expecting the implementation to be pretty much some kind of epic quest, given the number of classes that we dropped up front, I’m afraid you’ll be disappointed. In fact, creating the controller boils down to just defining a class that shields the functionality of the router and the dispatcher behind a ridiculously simple API:

<?php
namespace AcmeLibrary;

interface FrontControllerInterface
{
    public function run(RequestInterface $request, ResponseInterface $response);
}

<?php
namespace AcmeLibrary;

class FrontController implements FrontControllerInterface
{
    protected $router;
    protected $dispatcher;

    public function __construct(RouterInterface $router, DispatcherInterface $dispatcher) {
        $this->router = $router;
        $this->dispatcher = $dispatcher;
    }
    
    public function run(RequestInterface $request, ResponseInterface $response) {
        $route = $this->router->route($request, $response);
        $this->dispatcher->dispatch($route, $request, $response);
    }
}

All that the FrontController class does is employ its run() method for routing and dispatching a given request to the corresponding action controller by using the behind-the-scenes functionality of its collaborators. If you’d like, the method could be a lot fatter and encapsulate a bunch of additional implementation, such as pre/post dispatch hooks and so forth. I’ll leave this as homework for you in case you want to add a new notch to your developer belt.

To see if the front controller set up is actually as functional as it seems, let’s create a couple of banal action controllers which implement an execute() method:

其余：

http://phpmaster.com/front-controller-pattern-2/