Laravelプログラミングアーキテクチャ設計におけるアクションクラスの使用-PHPチュートリアル-php.cn

この記事では、Laravel プログラムアーキテクチャの設計アイデアにおけるアクションクラスの使用に関する関連情報を、サンプルコードを通じて詳細に紹介します。これは、学習や仕事に必要なすべての人の参考になります。エディターと一緒に学びましょう

まえがき

アプリケーションのアーキテクチャについて話すとき、私たちはよく尋ねます。古典的な質問です。それは、「このコードをどこに配置すべきか?」ということです。 Laravel はかなり柔軟なフレームワークであるため、この質問に答えるのはそれほど簡単ではありません。ビジネスロジックはモデル層、コントローラー層、または他の場所に記述する必要がありますか?

アプリケーションにアクセスポイントが 1 つだけある場合は、コントローラー層にビジネスロジックを記述しても問題ありません。しかし、現在では、同じ汎用モジュールを呼び出すアクセスポイントが多数あるという状況がより一般的になりました。

たとえば、多くのアプリケーションにはユーザー登録の機能があり、コントローラーを呼び出して、登録が成功したか失敗したかを示すビューを返します。このアプリケーションにモバイルバージョンもある場合は、返す必要があるデータ形式が JSON であるため、モバイルユーザー登録用の API セットが提供される可能性があります。また、特にプロジェクトの開発初期段階では、Laravel のアルティザンコマンドを使用してユーザーを作成することも非常に一般的です。

上記の 2 つのコードには問題がないように見えますが、ビジネスロジックが増加すると、コードが非常に冗長になっているように見えます。たとえば、新規ユーザーの登録後にユーザーに電子メール通知を送信する機能を追加する必要がある場合は、上記の両方のコントローラーに電子メールを送信するコードを追加する必要があります。ただし、コードをシンプルかつエレガントに保ちたい場合は、これらのビジネスロジックを別の場所に書くことができます。

「ビジネスロジックコードをどこに記述するか」という質問については、どのフォーラムでも共通の答えが得られます。それは、「サービス層を使用し、コントローラー層でこのサービスクラスを呼び出す」です。はい、そうです。問題は、サービスクラスをどのように設計すべきかということです。ユーザーに関連するすべてのビジネスロジックを実装する UserService クラスを作成し、このクラスを使用する必要があるコントローラー層に挿入することでしょうか?それとも他の選択肢があるのでしょうか？

神聖なクラスの落とし穴を回避する

まず、特定のモデルに対して、すべてのコードを含む単一のクラスを作成してみます。例:

完璧に見えます: 任意のコントローラーで create/delete メソッドを宣言または使用して、必要な結果を得ることができます。しかし、この実装の何が問題なのでしょうか?つまり、問題を解決する過程で単一のモデルを使用することはほとんどありません。

たとえば、ユーザーのアカウントを作成するときは、同時にユーザーの別のブログも作成する必要があります。このプロセスを現在の方法で実装する場合は、BlogService クラスを作成し、その依存関係を UserService クラスに注入する必要があります。

明らかに、アプリケーションビジネスが成長するにつれて、数十から数百のサービスクラスが存在し、その一部は他の 5 ～ 6 つのサービスクラスに依存する必要があります。最終的にはコードの冗長性と混乱が生じますが、これは何としてでも避けたい状況です。

単一アクションクラスの紹介

そこで、複数のメソッドを持つ単一のサービスクラスを使用する代わりに、サービスクラスをいくつかに分割することにしました。カテゴリ？以下は私が最近のすべてのプロジェクトで使用した方法であり、結果は非常に優れているので、皆さんにお勧めします。

まず、あまりにも一般的で曖昧なサービス用語を捨てて、新しいアクションクラスを見て、それらが何であるか、そして何ができるかを定義しましょう。

アクションクラスには、CreateOrder、confirmCheckout、DeleteProduct、AddProductToCart など、その機能を説明する名前が必要です。
API としてパブリックメソッドを 1 つだけ持つ必要があります。理想的には、 handle() やexecute() などの同じメソッド名である必要があります。これは、アクションクラスに何らかのアダプターパターンを実装する必要がある場合に非常に便利です。
リクエストとレスポンスに依存しない必要があります。リクエストは処理されず、応答も送信されません。そのような責任は管理者にあるはずです。
他のアクションクラスに依存する場合があります。
実行や期待値の返しを妨げるものがある場合は、例外をスローして関連するビジネスロジックを強制し、呼び出し元 (または Laravel ExceptionHandler ) に責任を負わせる必要があります。例外を提示/応答する方法については。

CreateUser アクションクラスを作成します

次に、前の例を取り上げ、 CreateUser という名前を付ける単一のアクションクラスを使用してリファクタリングしましょう。

#電子メールアドレスがすでに占有されているときに、なぜこのメソッドが例外をスローするのか疑問に思われるかもしれません。これは検証を要求することで保証されないのでしょうか？もちろん。しかし、ビジネスロジックはアクションクラス内で実行した方がよいのではないでしょうか。これにより、ロジックの理解とデバッグが容易になります。

アクションクラスを使用した後のコントローラーコードを次のように見てみましょう:

さて、どんな変更を加えても、ユーザーはregisters このプロセスは、API バージョンと Web バージョンによって、エレガントかつクリーンに処理されます。

アクションクラスのネスト

1000 人のユーザーをアプリケーションにインポートするアクションクラスが必要だとします。アクションクラスを作成し、上記の CreateUser クラスを引き続き使用することもできます。

なかなかいいですね。 CreateUser コードを Collection::map() メソッドに埋め込むことで再利用できます。これにより、新しく作成されたすべてのユーザーのコレクションが返されます。電子メールが占有されている場合、Null オブジェクトを返すか、それをログファイルに記録することができます。それについてはすでに考えられているはずです。

アクションクラスの装飾

次に、新しく登録されたすべてのユーザーをログに記録するとします。アクションクラス内にコードを記述することも、デコレーターパターンを使用することもできます。