Symphony、Laravel、そしてもちろんZendなどの一部のフレームワークでは、このテクノロジーが採用されています。
このすべては、多かれ少なかれMVCスキームに適合します。 おそらく永遠の議論がありました。アプリケーションの主要な結婚式のペアは何でしょうか-モデルとコントローラー？
私たちの中には、モデルはスリムで厚く、スリムでスリムなコントローラーでなければならない、と言われています。 一言で言えば-母性。
それどころか、長官はすべてを統治し、命令するべきだと信じているため、徹底的で十分に給餌されていることがわかります。 そして、彼と一緒に、細くて細身のモデル、その仕事は育てることです。 これが家父長制です。
それでは、MVCスキームの方が優れているのは何ですか？ 家父長制ですか、家父長制ですか？
民主主義に基づいて家族のセルを構築するという観点からこれを見てみましょう。 そして、Namespaceがこれを手伝ってくれます。
厚くて不器用なコントローラーは好きではありません。コントローラーは、中国の店の象のように、アプリケーション全体を不注意に押しつぶす可能性があります。
太ったモデルも好きではありません。 さて、誰が好きですか？ 彼らは表彰台に値するに違いない！
調和の取れたファミリーを作成するために、Namespaceを使用してみてください。
まず、アプリケーションフレームワークを作成します。 どんなに些細なことでも、ブログにしましょう。
メイン構造を作成しました。
- ブログはアプリケーションのリポジトリです。
- ビューとテンプレート-ビューとテンプレートのリポジトリ。
- ユーティリティ-共有ライブラリのリポジトリ。
- index.php-ブートストラップスクリプト。
- 投稿-これは、コントローラーとモデルの家族の牧歌が行われる場所です。
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でBlog \ Post \ Services \ Viewクラスが必要になります。
そして、これがネームスペースとの最初の会議です。
index.phpが起動すると、Blog / Blog.phpからクラスがロードされるBlogアプリケーションのインスタンスを作成します。
彼を見てみましょう。
<?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
-コントローラーリクエストに対応するサービス-ブログ\投稿\サービス\ View.php（サービスの1つなど）
<?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
-データベースとの対話システム-ブログ\投稿\リポジトリ\ 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
その結果、すべてのコンポーネントが適切に接続されたアプリケーション構造を作成できましたが、各クラスがタスクを実行するクラスの明確な分離を達成しました。 コントローラーは薄くて強力です。 彼に合うモデル。 完璧な家族！
名前空間のおかげです。
私は議論しません、多くの場合、フレームワークは便利です。 しかし、名前空間は何かを思い出させますか？
クラスへの明確な分割、厳密かつ同時に柔軟なディレクトリおよびクラスの階層は、開発者に完全に従属します。
フレームワークの形で数百のファイルやクラスの形でこのような重いアドオンが存在しないこともあります。
クラスとコンポーネントの相互作用のためのルールのプロクルステア層の欠如。
この記事は、Laravelフレームワークの作者であるTaylor Otwellによるこのトピックに関する考えに触発されたものです。
GitHubのソースアドレスの例： https : //github.com/oleg578/PHPNamespaceModel