ActiveRecordにおけるモデルの役割

現在、多くのフレームワークが ROR の ActiveRecord の例に従い、モデルをデータベース インタラクション レイヤーとして直接使用しています。多くのビジネスは 1 つのテーブルだけでなく、データベースの外部のロジックも含まれる場合があるため、これらのビジネス ロジックをコントローラーに入れて処理する必要があります。
これはコントローラーの本来の目的、つまりモデルとビューを接続するブリッジに違反していますか?
データ モデルとコントローラーの前に別のレイヤーを追加する必要がありますか?
皆さんはどうしましたか?データベースクエリとビジネスコールがすべてモデルに混在しています これを回避できるフレームワークはありますか?

簡単に言えば、ORM はデータベース内のリレーショナル データをプログラム内のオブジェクトとしてマッピングすることを指します

MVC では、M、V、C の間に明確な役割分担はありません
したがって、ビジネス ロジックの一部またはすべては、 C で完了 違反はありません
連続データを離散化するのと同じように、異なるしきい値を選択することで異なる結果を得ることができます。

ORM に基づくフレームワークはプロトタイプを提供するだけであり、特定のプロジェクトに適用する場合はさらに拡張する必要があると思います
アプリケーション プロジェクトの予測不可能性を考慮して、ほとんどの ORM は関連付けを提供しないか、インターフェイスのみを提供します

そこでモデルをテーブルベースからビューベースに変更した方が良いです(もちろんビューも予測不能です)

これはコントローラーの本来の目的、つまりモデルとビューを接続するブリッジに違反していますか?
データ モデルとコントローラーの前に別のレイヤーを追加する必要がありますか?
皆さんはどうしましたか?データベース クエリとビジネス呼び出しがモデルに混在していますか? これを回避できるフレームワークはありますか? ビューローはデータベースを特別なレイヤーでカプセル化し、データを処理する必要がある場合はモデルが処理します。カプセル化は と呼ばれます。データベース モジュールはさまざまなモデルを呼び出すために汎用的に使用することもできますが、コントローラーは制御に特化しているため、構造も非常に明確です。


現在、多くのフレームワークが ROR の ActiveRecord の例に従い、モデルをデータベース インタラクション レイヤーとして直接使用しています。多くのビジネスは 1 つのテーブルだけでなく、データベースの外部のロジックも含まれる場合があるため、これらのビジネス ロジックをコントローラーに入れて処理する必要があります。

データ モデルとコントローラーの前に別のレイヤーを追加する必要がありますか?
皆さんはどうしましたか?データベース クエリとビジネス呼び出しはすべてモデルに混在していますか? これを回避できるフレームワークはありますか? ビューローはデータベースを特別なレイヤーでカプセル化し、データを処理する必要がある場合はモデルが処理します。 、カプセル化はと呼ばれます。データベースモジュールはさまざまなモデルを呼び出すために汎用的に使用することもできますが、コントローラーは制御に特化しているため、構造も非常に明確です。

とてもお腹が空いた => 思う

学ぶ...素晴らしい仕事