PHP NameSpace — как же все-таки его готовить?

PHP, начиная с версии 5.3, подарил нам пространство имен. С тех пор идет где-то вялое, а где-то бурное обсуждение, как же это пространство имен использовать?
Некоторые фреймворки, такие как Symphony, Laravel, и, конечно же Zend взяли эту технологию на вооружение.
Все это более или менее вписалось в схему MVC. Осталась одна, наверное вечная, дискуссия, какой же должна быть главная брачная пара приложения — Модель и Контроллер?
Одни нам говорят, что Модель должна быть дородной и толстой и при ней стройный и тонкий Контроллер. Одним словом — матриархат.
Другие, наоборот, считают, что Контроллер должен всем управлять и повелевать, поэтому он получается основательный, упитанный. И при нем худенькая, стройненькая Модель, задача которой сводится к подай-принеси. Такой вот патриархат.
Так что же лучше в схеме MVC? Патриархат или матриархат?
Давайте посмотрим на это с точки зрения построения семейной ячейки на основе демократии. И пусть Namespace нам в этом поможет.

Нам не нравятся толстые, неуклюжие Контроллеры, которые, как слон в посудной лавке, по неосторожности могут раздавить все приложение.
Нам не нравятся также толстые Модели. Ну а кому они нравятся? Они должны быть достойны подиума!
Давайте попробуем с помощью Namespace, как с хорошей сватьей, создать гармоничную семью.

Сначала создадим каркас приложения. Как это ни банально, но пусть это будет блог.

Мы создали основну структуру, где:

• Blog — это хранилище нашего приложения;
• Views и Templates — хранилище представлений и шаблонов;
• Utility — хранилище общих библиотек;
• index.php — bootstrap скрипт;
• Post — вот здесь и должна состояться семейная идиллия Контроллера и Модели.

С index.php все просто:

<?php use Blog\Blog as Blog; /*  *   main application  */  define ("APP_PATH", "/home/oleg/www/viper.dev/"); define ("VIEW_PATH", "/home/oleg/www/viper.dev/Blog/Views/");  spl_autoload_register(function ($class) {       require_once str_replace('\\', '/', $class). '.php';        });  $blog = new Blog();  $blog->run();  /*  * end of index.php  */ 

Определяем нужные пути и создаем автозагрузчик.
Автозагрузчик загружает необходимые классы, которые расположены в иерархии папок согласно пространству имен класса. Например, класс Blog\Post\Services\View будет разыскиваться в Blog/Post/Services.
А вот и первая встреча с Namespace.
При старте index.php мы создаем экземпляр приложения Blog, класс которого загружается из Blog/Blog.php.
Посмотрим на него.

<?php namespace Blog; use Blog\Post\Post as Post;  class Blog   {     public $post;      public function __construct()     {         $this->post = new Post();     }      public function run()      {         $this->post->view->all();     }  }//end class Blog 

При создании класса Blog мы внедряем в него класс Post с Namespace Blog\Post и автозагрузчик загружает его из Blog/Post/Post.php.
Наверное, этот класс и можно назвать Контроллером,

<?php namespace Blog\Post; use Blog\Post\Services\View as View;  class Post   {      public $view;       public function __construct()       {          $this->view = new View();       } }//end class Post 

Сущность Post включает в себя:
— структуру самой записи данных — Blog\Post\Entities\PostEntity.php

<?php namespace Blog\Post\Entities;  class PostEntity {      public $id;      public $title;      public $body; }//end class 

— службы, обслуживающие запросы Контроллера — Blog\Post\Services\View.php (одна из служб, для примера)

<?php namespace Blog\Post\Services; use Blog\Utility\Contemplate as Contemplate; use Blog\Post\Repositories\Db as DB;  class View   {    public $db;    public function __construct()   {        $this->db = new DB();   }//end __construct    public function all()     {         $posts = $this->db->survey(); 	Contemplate::compose(array(          'header' => 'header',          'main' => 'main',          'footer' => 'footer',          ),          array(          'posts' => $posts,          'title'  => 'Viper site',          ));   } }//end class PostView 

— систему взаимодействия с базой данных — Blog\Post\Repositories\DB.php — вот она, наша тонкая, изящная Модель,
Только подай-принеси, и ничего больше!

<?php namespace Blog\Post\Repositories; use PDO as PDO;  class DB   {     private $dbh;      public function __construct()      {         $user = 'user';         $pass = 'parole';         try          {              $this->dbh = new PDO('mysql:host=localhost;dbname=test', $user, $pass, array(                 PDO::ATTR_PERSISTENT => true ));         } catch (PDOException $e) {               echo "Error!: " . $e->getMessage() . "<br/>";               die();         }     }//end __construct    public function survey()   {     $query_view = $this->dbh->prepare('SELECT * from posts');     $query_view->execute();     return $query_view->fetchAll(PDO::FETCH_CLASS, "Blog\Post\Entities\PostEntity");   }//end survey  }//end class Db 

В результате нам удалось создать структуру приложения, где все компоненты хорошо связаны, при этом мы добились четкого разделения классов, где каждый класс выполняет свою задачу. Контроллер у нас тонкий и в то же время мощный. Модель под стать ему. Идеальная семья!
И все багодаря Namespace.

Не спорю, во многих случаях удобен фреймворк. Но, посмотрите, Namespace вам ничего не напоминает?
Четкое разделение на классы, строгая, и в тоже время гибкая, полностью подчиненная разработчику иерархия каталогов и классов.
Отсутствие порою такого весомого довеска в виде сотен файлов и классов в виде фреймворка.
Отсутствие прокрустова ложа правил взаимодействия классов и компонентов.

Статья навеяна размышлениями на эту тему Taylor Otwell, автора фреймворка Laravel, за что ему огромное спасибо.
Адрес исходников примера на GitHub: https://github.com/oleg578/PHPNamespaceModel