この質問が非感覚であるかどうかわからない場合は、教えてください。データベース内の各テーブルごとに1つのモデルを作成するか、コントローラごとに1つのモデルを作成するのですか？私がここに欠けているものはありますか？良いASP.NET MVCを実装しようとすると、コントローラー '比率'の標準モデルはありますか？
私がモデルを読んだことは、実際のビジネスオブジェクトの表現であると思われるので、それを1つの大きなモデルにするか、アプリ内のものに基づいて分割したいのですか？データの実際のユーザー/クライアントの認識に基づいていますか？
ご協力いただきありがとうございます。
コントローラを共有するモデルには何も問題はありません。しかし、同じモデルを持つすべてのコントローラーにサービスを提供しようとすると意味がありません。
モデルとコントローラは実際には関連していません。モデルは、データがアプリケーションに格納される方法にも直接関係しません。
モデルはデータをカプセル化します。彼らのデザインは、カプセル化しているデータによって決まるはずです。システムの要求によって、必要なモデルとそのデータを保持する必要があります。
それを考え直してはいけません。特定のリクエストに対して、ビューに表示する内容とその表示方法を決定します。このシナリオで適切なモデルがどのように見えるかを決定します。すでに存在する場合は、それを使用してください。そうでない場合は、新しいモデルを作成します。あなたのニーズが分かっていて、モデル間の共通点を見いだすことができたら、後で強化してください。
モデルには他のモデルも含めることができます。販売レポートのモデルを考えてみましょう。レポートのモデルには、レポート名、合計だけでなく、レポートのラインアイテムを構成する他のモデルのコレクションも含まれます。
「モデル」の意味によって異なります。モデルによって、アプリケーションのビジネス・ルール・レイヤーを意味する場合、数値の関係はありません。そのタイプのモデルの1つは、作成する必要があるビューの量に使用されます。
個人的には、私はどのモデルにもビューをバインドしませんが、特定のビューに合わせてモデルからのデータを本質的に取り除くViewModelという中間層を作成します。その場合、関係は1対1です。これは本質的にPresenterパターンの仕組みです。すべてのビューは、モデルレイヤーから作成されたViewModel自体に強く型付けされています。
モデルには必ずしもデータベースとのリテラルコレスポンスがありません。あなたのモデルのデータの保存方法は、あなたの "モデル"がそのデータを使用する方法とは異なります。