イントロ
MVCデザインパターンはかなり古いものです。「web」が大学間でpingを送信する2人の男だったとき、元々はSmalltalk-80アプリケーション用に定義されていました。それ以来、それはかなり進化してきました。
MVCデザインパターンの背後にある中心的な原則は、関心の分離です。このパターンは、プレゼンテーションをビジネスロジックから分離します。プレゼンテーション層には主にビュー、コントローラー、テンプレート、ビューモデル、プレゼンターが含まれ(使用するMVCに触発されたパターンのフレーバーによって異なります)、ビジネスロジックはモデル層で終了します。
モデルレイヤーは、パターンで厳密に定義されていませんが、ASP.NET MVCでは、サービスと、サービスで使用されるすべての構造(ドメインオブジェクトとしてよく知られているモデルオブジェクトを含む)で構成されています。
質問に関して
DataContext
基本的なMVCチュートリアルを探している場合、コントローラーでの使用法を確認することは非常に一般的です。MVCアーキテクチャは大規模なアプリケーションを対象としており、Hello-Worldの例では、完全に実現されたMVCアーキテクチャは単なる肥大化のように見えます。
例では、簡単にするためにコードの分離を犠牲にしています。との相互作用DataContext
は基本的にストレージロジックであり、モデルレイヤーが処理するタスクの1つです。コントローラで使用すると、モデル層がプレゼンテーション層でリークし始め、「ファットコントローラ、スキニーモデル」の問題が発生することを意味します。
実際のアプリケーションでは、DataContext
はモデルレイヤー内の永続性を処理する構造の一部になります。おそらくデータマッパーの一部として、手動で書き込むことを選択した場合。
「更新」について
モデル(この場合はドメイン/モデルオブジェクトを意味していると思います)は、ViewModelとはまったく異なるアプリケーション層からのものです。
名前が示すように、MVVMパターンでは、ViewModelsがコントローラーに置き換わります。ViewModelは、モデルレイヤーからデータを取得し、Viewで使用できるように変換します。
このパターンは、ビューやモデルレイヤーの動作を完全に制御できない状況で(実際にMVVMを使用している場合)最適に使用されます。たとえば、SAPの代替フロントエンドを構築するために雇われた場合、またはビューが実際には特定のタイプの入力を期待する何らかの形式のハードウェアデバイスである場合。