PHPixieの仕組み-単一のリクエスト、コンテナ、パラダイムの寿命

PHPixieフレームワークとそのプログラミングについて何度も書いています。 今回は、アプリケーションのライフサイクルを調べて見ていきます。幸いなことに、コードの単純さと直線性により、比較的簡単にこれを行うことができます。



Symfonyと同様に、PHPixieは2つの部分で構成されます。コンポーネントライブラリとベースプロジェクトですが、PHPixieの場合、ベースプロジェクトはより薄く、いくつかのファイルのみで構成されます。 ここで彼は例の役割を果たしているため、自分で変更することは歓迎されるだけでなく、場合によっては必要になります。 このために、システムで何が起こっているのか、どのように起こっているのかを理解することが重要です。 ある程度限定された描画スキルを使用して、クエリ処理ダイアグラムを準備しました









もちろん、MVC（または、この場合はモデルを描いていないのでこの場合はVC）に既に精通している人にとっては、このスキームはおそらく馴染みがあるように思えますが、初心者にとっては非常に便利です。 したがって、すべてのクエリが到達するindex.phpから始めましょう。ここで最も重要な行は次のとおりです。

$pixie = new \App\Pixie(); $pixie->bootstrap($root)->handle_http_request();
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そしてすぐに、最も重要な部分であるApp \ Pixieクラスに到達します。これは、フレームワークの中心であるDIコンテナーです。 これにより、他のすべてのコンポーネントにアクセスできます。 App \ PixieはPHPixie \ PixieをPHPixie-Coreライブラリから継承します。 基本プロジェクトは、PHPixie \ Pixieを直接使用する代わりにこのクラスをアナウンスし、開発者に変更を加える機会を提供します（たとえば、モジュールをプラグインします）。



Silexのように、クラスですべてを明示的に記述する必要があるように、外出先でこのコンテナに新しいエンティティを追加できないことはすぐに注目に値します。 これは一見それほど便利ではないように思えるかもしれませんが、コードの読みやすさを向上させ、すべてのエンティティを完全に文書化（すべてがクラス属性になるため）し、IDEでこれらのエンティティに関するヒントを得ることができます。 PHPixie \ Pixieにはすべてのファクタリングメソッドも含まれているため、対応するメソッドをオーバーロードすることで、フレームワークのクラスを独自のクラスに簡単に置き換えることができます。



bootstrap（）メソッドは$ pixieを初期化し、構成を読み取り、例外処理を有効にします。 handle_http_request（）だけで、リクエストが処理されています。 このプロセスは3つの段階で構成されています。

• クラスPHPixie \ Requestの$ requestオブジェクトの作成
• このオブジェクトは適切なコントローラーに渡され、対応するアクションが実行されます。
• 実行中に、コントローラーは$応答オブジェクトを変更します（PHPixie \ Response）
• $応答からのデータ（ヘッダーとコンテンツ）がユーザーに送信されます

最も重要な$ request、$ response、および$ pixieオブジェクトの3つはすべて、PHPixie \ Controllerクラスの属性として使用できます。 次に、PHPixieコードを記述するためのいくつかのパラダイムについて少し説明しましょう。



因数分解法以外の場所では「new」演算子を使用しないでください。 新しいクラスにはそれぞれ、インスタンスを作成するための階乗メソッド（App \ Pixieなど）が必要です。 このアプローチにより、あるクラスを別のクラスに簡単に置き換えることができます。これは、単体テストを作成するときに特に重要です。 したがって、たとえばコントローラーのテストでは、ロックされたApp \ Pixieを渡すことができます。これは、実際のクラスの代わりにmokiを送信します。



静的なプロパティとメソッドを使用しないでください。 静的を使用すると、テストの記述が大幅に複雑になります。 PHPixieを使用すると、それらを使用せずに簡単に実行できます。App\ Pixieの属性としてインスタンスを追加するだけで、ほとんどどこからでもアクセスできます。 したがって、実際にはシングルトンを取得します。 ところで、これを$ instance_classesに追加することで実行できます。

 namespace App; class Pixie extends \PHPixie\Pixie { public function __construct() { $this->instance_classes['singleton'] = '\App\Singleton'; } } //     $pixie->singleton   , //      .     //         
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

モジュールの仕組み

PHPixieの各モジュールは、メインのPHPixe \ Pixieと非常によく似たDIコンテナを提供する追加のクラスライブラリです。つまり、モジュールに含まれるクラスインスタンスを作成するためのファクトリメソッドで構成されています。 次に、メインコンテナのモジュールの配列に追加します。

 namespace App; class Pixie extends \PHPixie\Pixie { protected $modules = array( 'db' => '\PHPixie\DB', 'orm' => '\PHPixie\ORM' ); } //     $pixie->db  $pixie->orm
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、たとえばPHPixie \ ORM \ ModelクラスをApp \ Modelに置き換えたい場合はどうでしょうか？ 簡単です。PHPixie\ ORM \ Modelの代わりに必要なものを返す独自のApp \ ORM（PHPixie \ ORMを拡張）get（）メソッドを作成する必要があります。 この中で、フレームワークのアイデアの1つがさらに現れます。何らかの魔法の代わりに、可能な限り標準のOOPテクニックを使用します。 たとえば、フレームワーク自体のクラスを置き換えるには、subclass_prefixを使用して、実際のプログラミングではなく構成レベルで実行する必要があります。 ほとんどの場合、クラス自体を見るだけでフレームワークについて何も知らなくてもファイルを理解できるため、このアプローチによりシステムの理解を大幅に向上させることができます。

しかし、フック、イベントなどはどうでしょうか？

彼らはそうではなく、私が理解しているように、そうではありません。 このようなことは、特にイベントに関してコードが非線形になるため、異なるパラダイムから完全になります。どのリスナーが最初に開始するのか、ある種のイベントを呼び出すとどうなるのかが常に完全に明確ではありません。 また、バックトレースはプログラマ自身がコードを確実に書いていない場所でフレームワーク自体によって呼び出されるため、バックトレースの可読性は非常に頻繁に使用されます。 どこかで何かをする必要がある場合、これを行うメソッドをオーバーロードし、必要なロジックを追加する方がはるかに簡単です。



次回の記事では、PHPixieがデータベースでどのように機能するかを詳細に調べるか、線形駆動とイベント駆動プログラミングの長所と短所をより広く説明します。