CodeIgniterコントローラーのビジネスロジック例分析、codeigniterコントローラー

CodeIgniterコントローラーのビジネスロジック例分析、codeigniterコントローラー_PHPチュートリアル

WBOY

リリース： 2016-07-12 09:00:07

オリジナル

923 人が閲覧しました

CodeIgniter コントローラーのビジネスロジックのサンプル分析、CodeIgniter コントローラー

この記事では、サンプルを通じて CodeIgniter コントローラーのビジネスロジックを分析します。参考のために皆さんと共有してください。詳細は次のとおりです:

前に分析したように、パブリックコントローラーは特定のモジュールの制御を容易にするためにモジュールごとに分散され、特定の実装クラスはライブラリに配置されます。図書館に置くのが適切でしょうか？また、コントローラー内のどこにさらにビジネスロジックを配置する必要があるでしょうか?

まず、CI のいくつかのフォルダーについて説明しましょう

ヘルパー、ライブラリ: コントローラーとビジネスロジックが機能を実装するのを支援する一連の補助関数と補助クラスを保存します。これらのメソッドは、CI への依存関係を避けるように努める必要があります。依存関係が緊密であればあるほど、再利用は難しくなります。電子メール送信を例に挙げると、エンコード、プロトコル、ポートなど、多くのパラメータは電子メール送信時に変更されません。これらのパラメータを config で設定すると、ライブラリが電子メール送信クラスをカプセル化し、その中に CI インスタンスを取得します。次に、これらのパラメータを読み取ります。現時点では、このクラスは CI フレームワーク内でのみ使用でき、他のシステムで使用される場合は書き換えられるだけであり、再利用の目的は達成されません。送信クラスがパラメータのみを受け取り、送信メソッドをカプセル化した場合はどうなるでしょうか?したがって、ヘルパーとライブラリはできるだけシンプルにして、単一の責任を持つようにしてください。

controllers: コントローラーのディレクトリ。コントローラーは主にプログラムを引き継いで接続の役割を果たします。通常、ビジネスロジックはアクション内に記述します。しかし、ビジネスが複雑になるにつれて、アクションコードはますます肥大化して保守が困難になります。

models: モデルディレクトリ。 CI モデルの主な役割は、データベースを処理してデータを取得することです。多くの場合、ビジネスロジックもモデルに組み込まれますが、ビジネスロジックとモデルは実際には別のものです。モデルはデータを取得するだけであり、ビジネスロジックでは、ビジネスニーズに応じてデータを結合することが考えられます。これをモデルに組み込むと、モデルの保守が困難になり、再利用が難しくなります。私が遭遇した例について説明します。データの取得と結果のキャッシュの 2 つのプロセスは同じメソッドで記述されていますが、同じデータを別の形式でキャッシュする必要があることがわかります。データの取得方法は再利用する方法がありません。

third_party: サードパーティのライブラリディレクトリ。クラスライブラリを取得した後は、それを直接使用しないでください。これをライブラリにカプセル化して、システムにより適したものにすることができます。これにより、他の人が使用することが難しくなくなります。

各フォルダーには独自の責任があり、各モジュールには独自のホームと独自の機能があることがわかります。ビジネスロジックはどうすればいいのでしょうか？

この場合、ビジネスロジックにホームを与え、ビジネスロジックを保存するための固有のディレクトリ (一時的にサービスという名前) を作成する必要もあります。コントローラーは主にパラメーターの受信とサービスの呼び出しを担当し、サービスはモデルを呼び出します。各層は独自の役割を実行します。

それを達成する方法を見てみましょう:

MY_Load を書き換え、サービスメソッドを追加し、コードをコピーして直接呼び出すことができますコードは次のとおりです: $this->load->service('user_service');。
ただし、多くのビジネスロジックでは CI インスタンスを取得する必要があります。ここでは、コアが MY_Service を作成し、他のサービスがこのクラスを継承するため、サブサービスでの使用法はコントローラーでの使用法と同じになります。

リーリー

実際、主なアイデアはビジネスロジックを処理するレイヤーを用意することであり、Java にはこのレイヤーがあります。 CI に詳しくなると、コントローラーとモデルを解放するためにこのレイヤーが必要であることがわかります。これと同様のアプローチが多数あり、システム内に Web サービスやキャッシュを使用する必要がある場所が多数ある場合は、実際に上記の考え方に従い、それらを別のフォルダーに配置して管理を容易にすることができます。

CodeIgniter 関連のコンテンツに興味のある読者は、このサイトの特別トピック「CodeIgniter チュートリアルの概要」および「CI (CodeIgniter) フレームワークの高度なチュートリアル」をチェックしてください

この記事が、CodeIgniter フレームワークに基づく皆様の PHP プログラム設計に役立つことを願っています。