私は、2 つの層に分割された階層的なユーザー構造を持つ FuelPHP アプリケーションを持っています。アプリケーションには、カスタム フィールドを使用できるチケット システムが含まれています。corporatestore
カスタム フィールドは、corporateレベルおよび/またはレベルで定義できstoreます。
レベルで定義されたカスタム フィールドはcorporate、「デフォルト」のカスタム フィールドとして機能します。つまり、「デフォルト」のカスタム フィールドを上書きしていないstoreの範囲内のユーザーは、それらのカスタム フィールドにアクセスできます。corporation
レベルで定義されたカスタム フィールドは、次のstoreいずれかを実行できます。
- 「デフォルト」(
corporateレベル) カスタム フィールドを上書きする - レベルで定義されていない追加
storeレベルのカスタム フィールドとして機能するcorporate
昨日、ストアの正しいフィールドを決定するロジックを書きました。store定義されたすべてのカスタム フィールドをデータベースから取得し、いくつかの比較を実行して、スコープに適したカスタム フィールドの配列を吐き出します。
最初はコントローラーにロジックを書きましたFieldsが、今日、アプリケーションの他の領域からそのデータにアクセスする必要があることに気付きました。多くの場合、Fields使用可能なコントローラーのインスタンスがありません (明示的に作成せずに)。
私は通常、自分のデータ モデルに多くのロジックを入れることをためらっています。それは、いつそれが適切なのかがわからないことが主な理由です。ただし、この場合、ロジックを静的に書き直しFieldて、メソッドとしてモデルに入れましたfor_store($id)。それは機能しますが、ここでひどく間違ったことをしていないことを確認したいと思います.
これは、コントローラーではなくデータ モデルに配置するようなロジックですか? 私の考えは次のとおりです。データを操作せずにデータにアクセスするため、データ モデルに属します。一方、実際にデータを変更する場合、それはコントローラーに属します。それは理にかなっていますか？
観点からのベストプラクティスに興味があります。MVC