私はMVCを勉強しています。私はMVCに関するいくつかの記事を読んだ。私が理解できる何asp.net MVCフレームワーク？
た：
ビューが直接モデルに通信することはありません単なるフロントエンドです。それはいつもControlerで直面しています。
コントローラは、Viewを受信して応答し、モデルと通信するソフトウェアコンポーネントです。
モデルは、すべてのプログラミング・ロジック、検証、データベース通信、サービスなど私の理解が正しい
ですが持っているのだろうか？
私はさらに学びたい：モデルでPOCOのclassessなります
？
すべての検証、db通信コードとビジネスロジックがあればモデル化されませんか？
モデルにmuplitleクラス/ライブラリがある場合は、それらのいずれかに直接会話できるかどうかを制御しますか？彼らはControlerに応答し、コントロールは再びViewと通信しますか？
ありがとうありがとうございました。
ビューはテンプレートとして考えることができます。ビューからのデータは、ビューで指定した場所に入力されます。ビューは、入力に使用されるフィールドを指定し、それらのフィールドがコントローラに送信される入力テンプレートにすることもできます。
コントローラは大部分の作業を行います。すべてのWeb要求はコントローラを通過します。コントローラは、ビューとモデルの間のメディエータとして機能します。コントローラはモデルをビューに渡し、ビューはモデルを受け取り、そのデータを使用してそのフィールドにデータを設定します。
モデルは、データモデルを定義する単なるデータオブジェクトの集合です。場合によっては、特別な機能を持たないスタンドアロンのクラスになることもあります。また、Entity Frameworkのようなツールから生成されるクラスになることもあります。
MVCは、メンテナンスが容易なように、ユーザーインターフェイスを別々のコンポーネントに分けるためのフレームワークです。
だけで基本：
モデル：これらは、データベースに格納され、必要なときに取得されます、昔ながらのC＃クラス（POCO）になります。私の意見では、ここではロジックが最小から最小になるはずです。データベース接続の確立、IMHOなどのことは、コントローラで処理する必要があります。
ビュー：レンダリングされたHTMLページは、データベース（POCO）から取得したデータに基づいていますか。これはプレゼンテーションのためのすべてのロジックを持つ場所です。例：マスターページを使用する。 PartialViewの挿入
コントローラ：ここにビジネスロジックがあります。これはリクエストを処理して、ビュー（ViewModels）用にモデルを設定することを意味します。
これは、開発中/開発中の作業を簡略化/明確化するための単なる抽象です。しかし、しばしばグレーの線があります。
ここでは、Facebookがどのようにユーザープロファイルを表示するかの非常に簡単な例です。第1に、所与のユーザに対する要求は、サーバによって適切なコントローラに引き渡される。コントローラーは要求を受け取り、どのユーザーの情報が要求されているかを把握し、データベースからユーザーデータを接続して取得し、データ/モデルを適切にフォーマットしてビューに渡します。ビューはレンダリングされ、モデルからデータを抽出してビューにレンダリングします。
Viewはモデルと直接通信しないフロントエンドです。それはいつもControlerで直面しています。
ビューはフロントエンドです。はい。 モデルをに変更するべきではありませんが、モデルから情報を取得する必要があるため、モデルを認識する必要があります。それはコントローラからモデルを受け取り、リンク/フォームを介してコントローラーと「対話」します。
コントローラは、Viewを受信して応答し、モデルと通信するソフトウェアコンポーネントです。
コントローラはビューを「受信」しませんが、ビューからのリクエストを受信します（必ずしも自分のビューの1つではありません）。したがって、リクエストには応答しますが、それ自体はビューではありません。 Modelを取得し、Requestに基づいてモデルを変更するためのModelメソッドの呼び出しを処理する必要があります（「モデルとの通信」）。モデルをビューに表示して表示します。
モデルは、モデルに配置することはできません多くの場合、すべてのプログラミングロジック、検証、データベース通信、サービスなど
ロジックやサービスを持っています。サービスは別々にする必要があります（それらは「M.V.C.」のいずれでもありません）。コントローラは一般に、アプリケーション固有のロジックが含まれています。検証がモデルで定義されている可能性がありますが（一部の純粋主義者はこれを好まない）、と表示するとと表示されます。データベース通信はモデル内にある場合もあれば、そうしたサービスがある場合もあります。
ここでモデルのPOCOクラスがありますか？
POCOクラスはモデルにあります。はい。 ViewModelクラス（これはPOCOクラスであることが多い）です。モデルには、さまざまな状況（同じデータを使用する場所が異なるため、同じデータを表す複数の方法を含む）のデータを表す多くのクラスがあります。
例：ユーザーオブジェクトのプロパティの一部を表し、「ユーザープロファイル表示」モデルとはまったく異なる「パスワード変更モデル」があるかもしれません。
データベース項目を直接表すモデルオブジェクトは、独自のライブラリに存在する可能性がありますが、ViewModelオブジェクトは別のライブラリに存在する可能性があります。あなたのモデルはコントローラまたはビューを認識してはいけません。ビューで必要なプロパティのみを考慮してViewModelオブジェクトを作成しますが、ViewModel自体にもビューに結びつけるコードはありません。
ありがとう@Mystere Man、あなたの説明から私はViewについて非常に明確です。 私はコントローラがビューとモデルの間を仲介しています。しかし、それはちょうどそれらの間のチャネルですか？またはそれにもいくつかのロジックがあります。フォームの例はどこでバリデーション、マニュアル作成、データベース操作コードですか？モデルやコントローラーで？ – haansi
@haansi - コントローラーにできるだけ少ないロジックが必要です。通常、ビジネスロジックを一連のサービスに渡して、それを実行すると、それらはコントローラから呼び出されます。 MVCの検証は、通常、モデルで定義されますが、フレームワークによって処理されますが、コントローラでの検証の失敗にのみ応答します。データベース操作は、通常、サービスやリポジトリに格納されます。これはコントローラから呼び出され、モデルを作成します。 –
ありがとうございました。 サービスにはdbロジックがあり、これらのサービスはコントローラによって呼び出されると述べました。 私の知らないことは申し訳なく思っていますが、これらのサービスモデルとは呼べません。 他のコンポーネントがあり、コントローラーがそれらを呼び出すことができますか？サービスはそのうちの一つですか？ もう一度申し訳ありませんが、私はモデルで混乱しています。フロントエンドが別の場合、どのモデルが使用されますか。 ビジネスロジックだけですか？ dbロジックをdbロジックの一部と呼ぶことはありませんか？ Plzガイド。 – haansi