エンティティとサービス
エンティティ
タスクがより複雑になり、すべてをデータベースに保存することが不可能になったため、プロジェクトに静的データエンティティを作成することにしました。本質は単純です。基本的な静的データは特定の場所に保存され、PHPコードで操作でき、それらの英語表現がデータベースに入力されます。
基本的なビューでは、Entity.phpクラスは次のようになります。
declare(strict_types = 1);
namespace entities;
class Entity {
protected static $map;
public static function getMap():array {
return static::$map;
}
}その相続人は、次のように受け取る$ mapプロパティを実装する必要があります。
E1::getMap();さらに、ほとんどの静的データは受信のロジックを満たします。データをグループ化したり、追加のデータを選択したりする必要がある場合、このロジックは継承されたクラスにすでに実装されています。
サービス
サービスは、アプリケーションのビジネスロジックを格納するように設計されています。さらに、サービスはフレームワークとは別のロジックとして使用できます。サービスは、アプリケーションのロジックを実装するメソッドのコレクションです。サービスに対して定義された条件：
- サービスは、コントローラーとビューに個別にアクセスするべきではありません。
- サービスは、データベース、モデル、およびエンティティにアクセスできます。
最良の場合、コントローラーは必要なすべてのデータをサービスに送信する必要がありますが、データを取得するために何らかのモデルを個別に参照する必要がある場合があります。これには何の問題もありませんが、コントローラーがデータルートで動作するというロジックに従うことをお勧めします。
デフォルトでは、サービスはプロジェクトの一部の一意の実行であるため、標準ロジックを実装していません。そのため、基本サービスクラスは作成しないことにしました。ただし、基本クラスは空の場合でも作成する方がよいことに注意してください。これは、すべての相続人が同じロジックを持つか、何らかのメソッドを実行する必要がある瞬間が来る可能性があるという事実によるものです。すべてのクラスで継承を変更しないようにするために、最初は基本クラスから継承する方が簡単です。この場合、この状況はそれほど複雑ではなく、一時的なリソースの点で安価です。
一般的に、提案されたアーキテクチャのデータフローは次のように表すことができます。
- データまたは要求はコントローラーに送られます。
- コントローラは、モデル、サービス、およびエンティティと双方向で通信します。ここで彼はいくつかのデータを受け取り、返します。
- このサービスは、データをコントローラーに送信し、データを受信またはモデルに送信します。
- コントローラは、受信したデータをビューに送信します。
したがって、アプリケーションのデータと動作原理は、基本的なMVC要素と新しい要素の間で分散されていることがわかります。
結論
このアプローチの導入により、アプリケーションの開発を大幅に簡素化し、データの流れを制御できるようになったことは注目に値します。ほとんどのデータはデータベースから取り出されたため、リクエストの数が減り、サイズが小さくなり、アプリケーション全体の速度が向上しました。