ホームページ >バックエンド開発 >PHPチュートリアル >CodeIgniterコントローラーのビジネスロジック例分析、codeigniterコントローラー_PHPチュートリアル
CodeIgniterコントローラーのビジネスロジック例分析、codeigniterコントローラー_PHPチュートリアル
- WBOYオリジナル
- 2016-07-12 09:00:07931ブラウズ
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 プログラム設計に役立つことを願っています。
興味があるかもしれない記事:
- CodeIgniter カスタム コントローラー MY_Controller 使用分析
- Codeigniter コントローラー コントローラー継承問題例分析
- 2 Codeigniter ファイル一括アップロード コントローラー記述例
- CodeIgniter フック使用例 詳細説明
- CodeIgniter 設定データベース。 php使用例分析
- CodeIgniter多言語実装方法詳細説明
- CI(CodeIgniter)モデル使用例分析
- CodeIgniterビュー使用上の注意点
- CodeIgniter読み書き分離実装方法詳細説明
- CI(CodeIgniter)簡単な使い方訪問者数の統計を実装します