Laravelプログラミングアーキテクチャ設計におけるアクションクラスの使用

この記事では、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 オブジェクトを返すか、それをログ ファイルに記録することができます。それについてはすでに考えられているはずです。

アクション クラスの装飾

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

その後、Laravel の IoC コンテナを使用して LogCreateUser クラスを CreateUser クラスにバインドできるようになり、後者のインスタンスが必要になるたびに前者が注入されるようになります。

#AppServiceProvider.php

これにより、構成変数または環境変数を使用してログ機能のアクティブ化または非アクティブ化を制御することがより便利になります。

AppServiceProvider.php

概要

このメソッドを使用するには、多くのクラスが必要になるようです。もちろん、ユーザー登録はコードを短く明確にするために設計された単純な例にすぎません。プロジェクトが複雑になり始めると、コードの場所とその境界が明確にわかるため、アクション クラスの真の価値がますます明らかになります。

シングル アクション クラスを使用する利点:

• 小規模で単一の論理ドメインにより、コードの重複を防ぎ、コードの再利用性を向上させ、安定性を維持できます。

• さまざまなシナリオに対する独立したテストを簡単に実施できます。

• 大規模なプロジェクトでは、意味のある名前の方が読みやすくなります。

#簡単に飾れます。
プロジェクト全体の一貫性: コントローラー、モデルなどの間でコードが分散されるのを防ぎます。
もちろん、この方法は、過去数年間に Laravel を使用した私の経験といくつかのプロジェクトでの実践に基づいています。これは私にとって非常にうまく機能し、今では小規模から中規模のプロジェクトでも使用しています。

別のアプローチがある場合は、ぜひ読んでみたいと思います。

上記がこの記事の全内容です。その他の関連コンテンツについては、PHP 中国語 Web サイトをご覧ください。

関連する推奨事項:

Laravel フレームワークは、操作ログ機能のためのミドルウェアの使用を実装します。

Laravel フレームワークは、リスナー SQL ステートメント記録関数を実行します

#

以上がLaravelプログラミングアーキテクチャ設計におけるアクションクラスの使用の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。