ASP.NET Core MVCは、Webアプリを**Model・View・Controller**の3つの責務に分けて構築するためのASP.NET Coreのフレームワークです。ブラウザからのリクエストはルーティングによってControllerのActionへ届き、Controllerが必要な処理やデータ取得を進め、最後にViewへ表示用データを渡してHTMLを返します。まずは『Controllerが入口、Viewが表示、Model側に状態や業務ロジックを寄せる』という流れを押さえると、既存コードを追いやすくなります。
まず整理：Model・View・Controllerは何を担当する？
| 要素 | 主な役割 | 置きすぎないもの |
|---|---|---|
| Model | アプリの状態・データ・業務ルールを表す | 画面表示の都合だけの処理 |
| View | RazorでHTMLなどのUIを表示する | データアクセスや複雑な業務ロジック |
| Controller | リクエストを受け、必要な処理を呼び、返すViewやレスポンスを決める | 長大な業務ロジックや表示ロジック |
Microsoftの公式ドキュメントでは、MVCは関心の分離を実現するパターンとして説明されています。ViewとControllerはModelを利用しますが、ModelはViewやControllerに依存しない形にすることで、UIから切り離してロジックを扱いやすくします。
用語解説：関心の分離
画面表示、入力処理、業務ロジックなど異なる責務を分ける考え方です。変更理由が違うコードを別の場所に置くことで、修正やテストの影響範囲を抑えやすくします。
リクエストはRouting→Controller→Model/ViewModel→Viewの順に流れる
- 1. ブラウザが`/products/42`などのURLへリクエストを送る
- 2. ASP.NET CoreのRoutingがURLをControllerのActionへ対応付ける
- 3. ControllerがAction引数を受け取り、必要なServiceやModel側の処理を呼ぶ
- 4. 表示用のViewModelを組み立てる
- 5. ControllerがViewへViewModelを渡す
- 6. Razor ViewがHTMLを生成してレスポンスとして返す
実際のアプリでは、Controllerからデータベースへ直接すべての処理を書くのではなく、Serviceやドメインロジックを挟む設計も一般的です。MVCの3語を『フォルダ名』として暗記するより、リクエスト処理の責務をどこに置くかで読むと理解しやすくなります。
最小構成を見るとMVCの役割がつながる
まずProgram.csでMVC用のServiceとController向けルーティングを登録します。
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddControllersWithViews();
var app = builder.Build();
app.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
app.Run();次にControllerのActionで表示用データを用意し、Viewへ渡します。
public class HomeController : Controller
{
public IActionResult Index()
{
var viewModel = new HomeViewModel("MVCの基本");
return View(viewModel);
}
}
public record HomeViewModel(string Title);Razor Viewでは受け取ったViewModelを表示します。
@model HomeViewModel
<h1>@Model.Title</h1>この小さな例でも、入口をController、表示をView、表示用データをViewModelへ分けています。実際の業務ロジックや永続化処理が増えても、Viewへ直接押し込まず責務ごとに分けるのが基本です。
ModelとViewModelは同じものではない
MVCのModelは広い概念で、アプリケーションの状態や業務ロジックを表します。一方、ViewModelは特定のViewが表示に必要なデータをまとめる型です。MicrosoftのMVC概要でも、厳密に型指定されたViewでは表示用データを持つViewModel型を使う設計が示されています。
| 観点 | Model / Domain側 | ViewModel |
|---|---|---|
| 目的 | 業務上の状態やルールを表す | Viewが必要な表示データをまとめる |
| 変更理由 | 業務仕様やデータ構造の変更 | 画面表示要件の変更 |
| Viewとの関係 | Viewへ直接渡すとは限らない | 特定View向けに設計できる |
データベースのEntityをそのままViewの都合へ寄せ始めた場合は、ViewModelへ分ける余地がないか確認します。
RoutingとModel BindingがControllerへの入口を整える
ASP.NET Core MVCはASP.NET CoreのRouting上に構築されています。規約ベースのルートでは`{controller}/{action}/{id?}`のようなパターンからActionを決められます。Attribute Routingを使ってControllerやActionの近くにルートを定義することもできます。
Controllerへ届いたフォーム値、Route値、Query StringなどはModel BindingによってActionの引数やObjectへ変換されます。そのため、Action側でHTTP入力を1つずつ文字列から組み立てるのではなく、型として受け取る設計ができます。
ControllerとViewを太らせないのがMVCを活かすポイント
Controllerはリクエストの入口なので処理を集めやすい一方、業務ロジックを大量に書くと責務が混ざります。MicrosoftのMVC概要でも、Controllerを過度に複雑にせず、ビジネスロジックをControllerから外すことが案内されています。
- Controller：入力を受け、必要な処理を呼び、結果を返す流れに集中する
- View：表示に必要なRazorとUIロジックへ絞る
- ViewModel：画面に必要なデータ形状を表す
- 業務ロジック：Domain ModelやServiceなど、UIから分離した場所へ寄せる
『Controllerに書けるから書く』『Viewで計算できるから計算する』ではなく、変更理由がどこに属するかで置き場所を決めると保守しやすくなります。
2026年時点でMVCはどんな位置づけ？
ASP.NET Core MVCは現在もASP.NET Core 10.0の公式ドキュメントで提供されている、成熟したサーバーサイドWeb UIの選択肢です。一方、Microsoftの現在の『Choose an ASP.NET Core web UI』では、新規プロジェクトの多くのWeb UIシナリオでBlazorを推奨しています。
そのため『ASP.NET Coreなら必ずMVCを選ぶ』と考えるのではなく、既存MVCシステムの保守、Controller/Viewの責務分離を活かしたサーバーレンダリング、大規模なMVC資産など、プロジェクトの前提に合わせて選びます。Razor PagesやBlazorとの詳細比較は別の検索意図なので、ここではMVCそのものの仕組みに絞ります。
ASP.NETとVB.NETを混同している場合は先に用語を分ける
ASP.NET CoreはWebアプリを作るための.NET側のフレームワーク群で、MVCはその中で使えるWebアプリ構築パターン／フレームワークです。VB.NETはプログラミング言語なので、同じ階層の用語ではありません。
（ASP.NETとVB.NETの用語差から整理したい場合については『ASP.NETとVB.NETの違いとは？初心者が知っておきたい選び方と学習のポイント』をご参照ください）
よくある質問
ASP.NET Core MVCのModelはデータベースのテーブルと同じですか？
必ずしも同じではありません。Modelはアプリケーションの状態や業務ロジックを表す広い概念です。Entity、Domain Model、表示用ViewModelなどを目的に応じて分ける設計があります。
Viewにデータベースアクセスを書いても動きますか？
技術的に書ける場合があっても、Viewは表示に集中させるのがMVCの責務分離に合います。データ取得や業務処理はControllerから呼ぶServiceやModel側へ分ける方が、テストや変更の影響を管理しやすくなります。
ASP.NET Core MVCでAPIも作れますか？
はい。ASP.NET Core MVCはWebアプリだけでなくWeb APIの構築にも対応しています。ただし画面用Controller/ViewとAPI Controllerでは返すレスポンスや設計目的が異なるため、用途を分けて考えます。
新規開発ならMVCを選べばよいですか？
一律ではありません。Microsoftは現在、多くの新規Web UIシナリオでBlazorを推奨しています。MVC、Razor Pages、Blazorなどを要件・既存資産・チーム経験に合わせて比較します。
まとめ：MVCは3つの名前より「責務と処理の流れ」で理解する
- Controllerがリクエストを受け、必要な処理と返す結果を調整する
- Model側にアプリの状態や業務ロジックを寄せる
- ViewはRazorで表示を担当し、業務ロジックを抱え込まない
- ViewModelを使うと画面表示用データを業務Modelから分けやすい
- RoutingとModel BindingがHTTP入力からController Actionまでをつなぐ
- 現在の新規UI選択ではMVCを自動採用せず、Blazorなど他の選択肢も要件に合わせて比較する
既存のASP.NET Core MVCコードを読むときは、URLに対応するController Actionを見つけ、そこからViewModelとViewへ順に追うと、処理の全体像をつかみやすくなります。
