PHP NameSpace - how to cook it?

PHP, starting with version 5.3, gave us a namespace. Since then, there has been a sluggish somewhere, but somewhere there is a heated discussion, how can we use this namespace?
Some frameworks, such as Symphony, Laravel, and, of course, Zend have adopted this technology.
All this more or less fit into the MVC scheme. There is only one, probably eternal, discussion, what should be the main marriage couple of applications - Model and Controller?
Some of us are told that the Model should be long and thick and with it a slim and thin Controller. In a word - matriarchy.
Others, on the contrary, believe that the controller should manage and rule everything, so it turns out to be solid, well-fed. And with him a slim, slim Model, whose task comes down to bring-bring. Such is the patriarchy.
So what's better in the MVC scheme? Patriarchy or matriarchy?
Let's look at it from the point of view of building a family unit based on democracy. And let Namespace help us with this.

We don’t like thick, clumsy Controllers, which, like an elephant in a china shop, can inadvertently crush the entire application.
We don't like fat models either. Well, who likes them? They must be worthy of the podium!
Let's try using Namespace, as with a good matchmaker, to create a harmonious family.

First, create an application framework. No matter how trite, but let it be a blog.
')


We have created a basic structure, where:

• Blog is the repository of our application;
• Views and Templates - a repository of views and templates;
• Utility - repository of shared libraries;
• index.php - bootstrap script;
• Post - this is where the family idyll of the Controller and Model should take place.

With index.php, everything is simple:

<?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 */ 

We define the necessary paths and create an autoloader.
The autoloader loads the necessary classes that are located in the folder hierarchy according to the class namespace. For example, the Blog \ Post \ Services \ View class will be searched for in Blog / Post / Services.
And here is the first meeting with Namespace.
When we start index.php, we create an instance of the Blog application, whose class is loaded from Blog / Blog.php.
Let's look at it.

 <?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 

When creating the Blog class, we embed the Post class in it with Namespace Blog \ Post and the autoloader downloads it from Blog / Post / Post.php.
Probably, this class can be called a controller,

 <?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 

Entity Post includes:
- the structure of the data record itself - Blog \ Post \ Entities \ PostEntity.php

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

- services serving controller requests - Blog \ Post \ Services \ View.php (one of the services, for example)

 <?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 

- database interaction system - Blog \ Post \ Repositories \ DB.php - this is our thin, elegant Model,
Just bring and bring, and nothing more!

 <?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 

As a result, we managed to create an application structure, where all components are well connected, and we achieved a clear separation of classes, where each class performs its task. Our controller is thin and powerful at the same time. Model to match him. Perfect family!
And all thanks to Namespace.

I do not argue, in many cases the framework is convenient. But look, does Namespace remind you anything?
A clear division into classes, a strict, and at the same time flexible, fully subordinate to the developer hierarchy of directories and classes.
The absence of such a weighty appendage in the form of hundreds of files and classes in the form of a framework.
Lack of procrustes bed rules for the interaction of classes and components.

The article is inspired by reflections on this topic by Taylor Otwell, author of the Laravel framework, for which he thanks a lot.
The source address of the example on GitHub: https://github.com/oleg578/PHPNamespaceModel