ユーザー情報を含む 3 つのテーブルがあります。1 つは学生用、もう 1 つは教師用、もう 1 つは管理者用です。
それらは決して関連していません。学生と教師のリストが表示される管理者用のダッシュボードを作成したくありません。
これを達成する唯一の方法$uses
は、管理者コントローラーで変数を使用することでした。しかし、私はこれが悪い習慣であると多くの場所で読みました。
解決策はありますか?
ユーザー情報を含む 3 つのテーブルがあります。1 つは学生用、もう 1 つは教師用、もう 1 つは管理者用です。
それらは決して関連していません。学生と教師のリストが表示される管理者用のダッシュボードを作成したくありません。
これを達成する唯一の方法$uses
は、管理者コントローラーで変数を使用することでした。しかし、私はこれが悪い習慣であると多くの場所で読みました。
解決策はありますか?
もう1つの、おそらくより良い方法は、ClassRegistry::init('MyModel')->myMethod()
(@ Cake APIをもっと読む)を使用することです
これは、モデルがシングルトンとして扱われるloadModel
oruses
とは対照的に、オブジェクトが使用されたときにのみロードします。ClassRegistry
--
何か間違ったことをしている: 現在のコントローラーとは関係のないモデルにアクセスする必要があります。
1 つのコントローラーからすべてのモデル データにアクセスする必要がある状況はたくさんありますが、慣習を破らずにアクセスする方法についての決定的な答えはありません。
を使用して、関連していない別のモデルをいつでも使用できます
$this->loadModel('NewModelName');
次に、次の方法で、新しく読み込まれたモデルにアクセスできます。
$this->NewModelName->add(); // whatever method model has defined
使用よりも loadModel() を好むのはなぜですか?
パフォーマンスを得るために。どのように?uses は、loadModel 関数自体を呼び出して、uses 配列で指定したすべてのモデルを読み込みます。しかし問題は、アクションの 1 つだけが特定のモデルを必要とする場合、それをすべてのアクションに含めることは良いことです。たとえば、 add() アクションのみが無関係のモデルを必要としますが、それを uses 配列で指定した場合、どのアクションが呼び出されても、まったく無関係のモデルがロードされます。簡単に言えば非効率です。Cプログラムで変数を宣言したが、それらを使用したことがないようなものです。C コンパイラの場合、変数を使用していないことが警告されますが、残念ながら Cake はそれを通知できませんでした。
すべてのアクションがそのモデルをロードする必要がある場合は uses を使用しても問題ありません。それ以外の場合は loadModel() を使用してください。
あなたはおそらくあなたの他の質問で私の答えを読んでいません:))
ユーザー情報を含む 3 つのテーブルがあります。1 つは学生用、もう 1 つは教師用、もう 1 つは管理者用です。それらは決して関連していません。学生と教師のリストが表示される管理者用のダッシュボードを作成したくありません。
問題は、同様のデータを 3 つの異なるテーブル (この場合はユーザー情報) に分けていることです。したがって、このデータを管理しようとすると、レンガの壁にぶつかります。3 つのテーブルに関係を分離するときに関係を除外するためです。
これを実現する唯一の方法は、Administrators コントローラーで $uses 変数を使用することでした。
あなたはコントローラーについて間違った考えを持っています。各コントローラーは、特定のモデル (および関連するモデル) のデータ フローを管理します。管理作業を行うために管理コントローラーにとどまる必要があるという意味ではありません。操作するモデルによって、必要なコントローラーが決まります。
しかし、私はこれが悪い習慣であると多くの場所で読みました。
主な質問: $uses を使用することは、何か間違ったことをしている危険信号です: 現在のコントローラーとは関係のないモデルにアクセスする必要があります。さて、プログラミングには常に例外があり、そのモデルにアクセスする必要がある場合があります。そこで loadModel の出番です。モデルがたくさん必要な場合は、loadModel をたくさん呼び出す必要があります。これは面倒です。これは $uses の目的ですが、それはアプリの設計に何か問題があることを意味します :))
したがって、$uses の使用は (DB 設計またはアプリケーション構造における) 悪い決定の兆候であると言えます。そのため、loadModel を頻繁に使用しています。
編集:Any solutions?
他の質問で1つの解決策を提供しました。ただし、それらすべてを 1 か所にまとめたい場合は、ユーザー情報を含む 1 つの users テーブルを使用できます。各ユーザーは、ユーザーがどのグループであるかを決定するために、1 つの生徒、教師、管理者、および「グループ」フィールドを持つことができます。3 番目の解決策は、$uses を使用することです。そのパフォーマンスへの影響は実際には問題になりません。しかし、アプリをさらに開発すると、かなり複雑になります。それはあなたが心配する必要があるものです。たとえば、Auth を使用する場合、3 つのモデルで動作させるには、かなり微調整する必要があると言えます。users テーブルを使用すると、はるかに簡単になります。