私はいつもユーザー認証を に入れてきましapplication/models/user_model.php
たが、機能を入れるのに本当に最適な場所ですか?
このコーディング方法について疑問を抱くのは、モデルはデータベースでのみ機能するはずだと聞いたことです。したがって、セッション関連のものをモデルに含めることはできません。本当にそうですか?
user_model
のオートローディングモデルを介して関数にアクセスできるようにしconfig/autoload.php
ます。
私はいつもユーザー認証を に入れてきましapplication/models/user_model.php
たが、機能を入れるのに本当に最適な場所ですか?
このコーディング方法について疑問を抱くのは、モデルはデータベースでのみ機能するはずだと聞いたことです。したがって、セッション関連のものをモデルに含めることはできません。本当にそうですか?
user_model
のオートローディングモデルを介して関数にアクセスできるようにしconfig/autoload.php
ます。
これは、実際の MVC および MVC にインスパイアされたデザイン パターンのモデル レイヤーの一部である必要があります。これは、ビューが認証/認識サービスを通じて調べる必要があるdomain objectlogged-in
の状態になるためです。
この投稿を読むと役立つかもしれませんが、簡単なヒントを次に示します。モデルは SQL データベースやその他の特定のストレージ メディアに関連付けられていません。セッションは単なる別の形式のストレージです。
残念ながら、CodeIgniter は実際には MVC や MVC にインスパイアされたデザイン パターンを実装しているのではなく、Rails をコピーしています。これは、CI で適切なモデル レイヤーを実装する必要がない限り (これは簡単ではありません)、CodeIgniter が「コントローラー」と呼ぶこのチェックインを実行する必要があることを意味します。
アップデート
承認チェックをコントローラーの外部に配置する方法を検討することをお勧めします (ここで説明されているように)。このようにして、コードの実行をさらに制御し、現在のユーザーがメソッドにアクセスする権限がないことを検出したときに、選択したコントローラーに「ロックイン」されることはありません。
コントローラー内で承認チェックを行うと、クライアントをリダイレクトすることになり、何かが変更されたときに各コントローラーを書き換える必要があります (したがって、OCPに違反します)。
認証サービスの初期化と承認チェックの実行をコントローラーの外部に配置することは、MVC の考え方に反するものではありません。MVC の定義では、ビューはモデル レイヤーと現在のビューの状態の変更のみを担当するためです。それらのインスタンス化については何も言われていません。したがって、コントローラーでアクションを実行する前に、認証サービス (モデル層の一部) を初期化しても問題ありません。