3

CakePHP のコントローラーに、URL でアクセスできないプライベート関数を含めるべきではないかどうか疑問に思っていました。

追加や削除などの一部の関数は非常に大きく、分割した方がよい場合があります。コントローラーでプライベートにするのではなく、その関数をモデル内に配置する必要がありますか?

ありがとう。

4

4 に答える 4

4

ええ、モデルにメソッドを保持するのがおそらく最善です。あなた自身がコメントで述べたように、「モデルを太くし、コントローラーを薄くしてください」。コントローラーは、モデルとビューの間で対話することになっている単なる媒体です。

問題は、データソースやテーブルの変更に対処しなければならないときに発生します。コントローラーが太い場合は、どこでもフィールドを使用していたはずであり、セットアップ全体を本来あるべきではない場所でクリーニングする必要があります。

モデル内のメソッドの追加の利点は、他のモデルから呼び出してコードを再利用できることです。例えば：

class User extends AppModel {

     public function getAllActiveUsers() {
         // return active users
     }

}

上記のメソッドは、ユーザーに関連するモデルとコントローラーの両方の他のすべてのメソッドからアクセスできます。

そのような関数が別の場所で必要であり、User モデルで定義されていない場合は、最終的にコントローラーにリダイレクトするか、ロジック全体を最初から書き直すことになります。

リダイレクトはそれほど悪くはありませんが、別の場所でロジックを書き直し、ActiveUsers の実装を変更した場合にどうなるかを考えてみてください。どこでも問題を修正する必要があります。

ただし、コントローラーで実行する必要があることがいくつかあります。たとえば、ユーザーの地理位置情報と一致するすべてのレストランの間の近くの距離を計算する必要がある場合は、コントローラーでこれを行う必要があります。しかし、コントローラーを薄型のままにし、この目的のためにコンポーネントが存在することが最善の方法です。複雑で長いロジックのカスタム コンポーネントを作成できます。

于 2012-09-21T16:50:08.533 に答える
1

データベースへのエントリの追加と削除を処理するロジックは、ドメイン ビジネス ロジックの一部です。このようなメソッドは、モデル レイヤーの一部である必要があります。

CakePHP の実装は非常に制限されているため (モデル層がアクティブなレコード インスタンスのコレクションであると見なされます)、これらのメソッドをある種のヘルパーに移動するか、から継承しない別の「モデル」を使用することができAppModelます。代わりに、そのような構造は、ドメイン ビジネス ロジックからコントローラー (およびプレゼンテーション層全体) を分離するサービスのように機能することができます。

于 2012-09-21T21:00:35.890 に答える
1

モデルに低レベルの関数を入れました。特に、その機能が複数のコントローラーで使用できる場合。「低レベル」とは、可能な限りモデル データに近いことを意味します。データにビュー固有の変更を加えたり、他のモデルのデータと組み合わせたりする場合 (関連するモデルは例外です)、関数はモデルに属しません。

また、コントローラー関数の前にアンダースコアを付けるだけでも、URL からは利用できません。

于 2012-09-21T18:18:56.243 に答える
-2

いいえ。CakePHP はフレームワークです。再利用可能なロジックのビットに対してプライベート関数を自由に作成してください。奨励されているのではないでしょうか。

于 2012-09-21T15:35:19.893 に答える