※この記事は、普段WPFを使っている「ががん」とChatGPTとの質疑応答をもとに、ChatGPTこと「ドイ」が構成・執筆しています。
—
先日、ががんが個人用ダッシュボードを作り始めた。
最初はASP.NET Core Razor Pagesで作る予定だったが、途中で技術構成について話しているうちに、最終的にはBlazorを使ってみることになった。
その途中で、こんな疑問が出てきた。
「そもそもMVCって、MVVMみたいなアーキテクチャの話じゃないの？」
普段WPFを触っているががんにとって、MVVMは馴染みがある。
一方で、MVC、Razor Pages、Blazorの違いについては、なんとなく聞いたことがある程度だったらしい。
ということで今回は、そのときのやり取りをもとに、それぞれの違いと、なぜ今回Blazorを使うことになったのかを整理してみる。
MVCとMVVMは同じ種類の話？
まず最初に出てきたのが、
「MVCって、MVVMみたいなアーキテクチャの話だと思ってたけど、認識合ってる？」
という疑問。
これは、おおむねその認識で合っている。
MVCは、
- Model
- View
- Controller
MVVMは、
- Model
- View
- ViewModel
に役割を分ける考え方だ。
普段使っているWPF + MVVMでは、ViewとViewModelをデータバインディングでつなぐ。
ViewModelの状態が変われば画面に反映され、画面からの入力もViewModelに渡すことができる。
一方のMVCでは、Controllerがユーザーからの要求を受け取り、必要な処理を行い、その結果をViewに渡す。
この話をしていると、ががんからこんな感想が出てきた。
「MVCが古典的なWindows Formsっぽく感じるな」
MVCはWindows Formsっぽい？
確かに、Controllerがユーザーからの要求を受けて処理するところだけを見ると、Windows Formsのイベントハンドラに少し似て見える。
ただ、役割の分け方はかなり違う。
典型的なWindows Formsでは、Formが画面そのものであり、その中にイベントハンドラも書ける。
ボタンを押したら処理をして、そのまま画面上のコントロールを書き換えることもできる。
つまり、画面と処理が同じFormの中に存在できる。
一方、MVCでは画面を担当するViewと、処理を取り仕切るControllerが分かれている。
Controllerは処理結果をViewに渡すが、Windows Formsのように画面上のコントロールを直接書き換えるわけではない。
似て見えたのは、どちらも「ユーザーからの操作や要求を受けて処理する」という部分だったようだ。
そして、ここで新しい疑問が出てきた。
「Webだと、Viewにあたるのがどこになるの？」
WebのViewは「画面そのもの」ではない
Windows FormsやWPFでは、画面そのものがアプリケーションの中に存在している。
そのため、画面上のコントロールや、画面が持っている状態を扱う感覚がある。
一方、昔ながらのWeb MVCは少し違う。
ざっくり書くと、
- ブラウザからリクエストが来る
- Controllerが処理する
- Viewを使ってHTMLを生成する
- 生成したHTMLをブラウザに返す
という流れになる。
ASP.NET Core MVCであれば、.cshtmlファイルがViewにあたる。
ここでいうViewは、Windows FormsやWPFのように「今そこに表示されている画面そのもの」というより、ブラウザに返すHTMLを作るためのものと考えると分かりやすい。
HTMLをブラウザに返したあと、Controllerがその画面を直接操作するわけではない。
普段デスクトップアプリを触っていると、この辺りの感覚が少し違う。
この違いが分かると、なぜBlazorがWPF経験者に少し馴染みやすく感じるのかも見えてくる。
その前に、今回最初に使おうとしていたRazor Pagesについても整理しておく。
Razor Pagesは何なのか
今回のダッシュボードは、最初はRazor Pagesで作る予定だった。
Razor Pagesは、ページ単位でWebアプリを作りやすくした仕組みだ。
例えば、
Index.cshtmlIndex.cshtml.cs
というファイルをセットで扱う。
Index.cshtmlが表示を担当し、Index.cshtml.csのPageModelが、そのページに必要な処理やデータを担当する。
MVCではControllerとViewが別々に存在するが、Razor Pagesではページを中心に必要なものがまとまっている。
そのため、
「ページを表示する」
「入力する」
「送信する」
といった、ページ単位で完結しやすいWebアプリでは分かりやすい。
ただし、基本的にはサーバーで処理をしてHTMLを返すWebアプリであることに変わりはない。
もちろん、MVCやRazor Pagesでも画面の一部分だけを更新することはできる。
ただ、画面をどんどん動的にしていこうとすると、JavaScriptなどを組み合わせる場面も増えてくる。
Blazorは「画面を作る感覚」が少し違う
Blazorでは、画面をコンポーネントとして作ることができる。
コンポーネントは状態を持つことができ、その状態が変わると画面も更新される。
例えば今回のようなダッシュボードなら、
- Twitchの情報を表示するコンポーネント
- 株価を表示するコンポーネント
- TODOを表示するコンポーネント
といった形で、それぞれを分けて作ることができる。
それぞれが別々の状態を持ち、必要に応じて表示を更新していく。
この辺りは、WPF + MVVMで「状態が変わるとUIにも反映される」という世界に慣れているががんには、比較的イメージしやすかったようだ。
ただし、BlazorがMVVMというわけではない。
MVCやMVVMは、アプリケーションの役割をどう分けるかという設計上の考え方。
Blazorは、C#を使ってWeb UIを作るためのフレームワーク。
Razor Pagesも含め、厳密にはすべてが同じ種類のものというわけではない。
今回は「ASP.NET CoreでWebアプリを作るなら、どういう作り方があるのか」という話の中で比較していたため、並んで登場していたということになる。
BlazorとInteractive Serverも別の話
今回作ったダッシュボードは、
.NET 10 Blazor Web App + Interactive Server
という構成になっている。
ここでも最初は少し混乱があった。
Blazorは、C#でWeb UIを作るための技術。
Interactive Serverは、そのBlazorのUIをどこで実行し、ブラウザとどうやり取りするかを決める方式の一つ。
Interactive Serverでは、C#の処理は主にサーバー側で動く。
ブラウザとサーバーは接続を維持しながらやり取りし、状態が変わると必要な部分の画面が更新される。
この仕組みを聞いたががんからは、
「これ、多人数向けのWebアプリには向かなそうな気がする」
という疑問も出てきた。
実際、Interactive Serverではユーザーごとの接続や状態をサーバー側で扱うため、利用者が増えれば同時接続数やサーバー負荷などを考える必要がある。
ただし、これはBlazorそのものの話ではない。
Blazorには、ブラウザ側で処理を動かすInteractive WebAssemblyなど、別の実行方式もある。
今回作るのは、基本的には自分で使うための個人用ダッシュボード。
そのため、まずはInteractive Serverで始めても特に問題はなさそうだ。
なぜ今回はBlazorなのか
ここまで話してきたが、BlazorがMVCやRazor Pagesより優れている、という話ではない。
単純なページを作るならRazor Pagesの方が分かりやすいこともある。
MVCが向いているアプリケーションもある。
今回のポイントは、今のががんとの相性だった。
普段はWPFとC#を使っている。
Webアプリはほとんど触らない。
Web開発そのものを体系的に勉強することが目的でもない。
そして作りたいのは、色々な情報を一つの画面にまとめる個人用ダッシュボード。
今後、表示する情報が増えていけば、それぞれをコンポーネントとして追加していくことができる。
それぞれの情報が変化したときも、コンポーネント単位で状態を扱える。
MVCやRazor Pagesでも動的な画面を作ることはできるが、そのためにJavaScriptなど、別の技術を扱う場面も増えてくる。
一方、Blazorなら使い慣れたC#を中心に、そのまま動的なWeb UIを作り始めることができる。
もちろん、Blazorを使えばJavaScriptが一切必要なくなるわけではない。
ただ、少なくともJavaScriptを覚えないとスタートできないわけではない。
つまり今回の結論は、
「Blazorが一番優れている」
ではなく、
「今のががんが持っている知識と、今作りたいものにはBlazorがかなり都合がいい」
ということだった。
そんなわけで、ががんの個人用ダッシュボードはBlazorで作っていくことになった。
現時点では、まだ「Hello, world!」しか表示されていない。
果たして、ここからちゃんとダッシュボードになるのだろうか。
補足
この記事は、普段WPFを使用している「ががん」とChatGPTとの質疑応答をもとに、ChatGPTこと「ドイ」が構成・執筆しました。
内容についてもChatGPTが整理しているため、今後実際にBlazorを触っていく中で認識が変わったり、補足したいことが出てきたりするかもしれません。
そのときは、また続きを書こうと思います。
コメント