ASP.NET Core MVCを新人に説明するに当たって、概念的なところも言語化する必要に迫られたのでまとめです。
とことんまで聞いてくる意欲旺盛な新人を想定して、背景まで言語化してみます。
前提
- 今回の案件ではASP.NET Core MVCを使って開発します。
- データアクセスにはEntityFrameworkを使います。
新人からの質問
Q. ASP.NET Core MVCとはなんですか？
A. MVCフレームワークを実現する、Webフレームワークです。
ASP.NET Core上で動きます。
Q-1. MVCフレームワークとはなんですか？
A. WebアプリケーションをView、Controller、Modelという三つの役割に分けることで、それぞれのコンポーネントの役割と依存関係を明確化するアーキテクチャです。
ASP.NET Core MVCやC#だけでなく、Javaのシステムでも使われるアーキテクチャです。
オブジェクト指向のWebアプリケーションであれば、どの言語でも適用できます。
Q-1-1. コンポーネントってなんですか？
A. システムを構成する部品のことをコンポーネントといいます。
具体的に言うと、今回の場合はクラス + cshtmlです。
Q-1-1-1. cshtmlってなんですか？
A. C#のコードを埋め込めるHTMLのようなものです。
C#のコードを埋め込めるHTMLの構文をRazor構文といい、そのRazor構文が書かれたファイルの拡張子がcshtmlです。
for文とかif文や、変数が使えるので動的にHTMLページが構築できます。
Q-1-2. アーキテクチャってなんですか？
A. ソフトウェアの構造のことです。
例えば
○○の役割を持っているクラスは、××のクラスからしか呼ばれないようにしよう。とか
○○の役割を持っているクラスは、それ以外の機能を持たないようにしよう。といった
1つのクラスがどんな機能を持つのか。そのクラスの機能が誰に、どういった場合に呼ばれるのか。などの決まり事の集合体（＝構造）のことをいいます。
Q-1-3. Viewってなんですか？
A. ブラウザの画面を表示するところです。
どこに何のデータを表示するのかーとかどうやって表示するのかーといったことを行う奴らです。
上記のcshtmlが該当します。
Q-1-4. Controllerってなんですか？
A. ViewとModelの間でデータの受け渡しや機能の呼び出しを行う仲介屋です。
仲介するだけならいらなくない？と思うかもしれないけど、ViewとModelを一つの機能としてまとめあげる重要なポジションです。
Controllerがクライアントからのリクエストを最初に受け取り、Modelを呼び出してデータを取得し、取得したデータをViewに渡します。
実働はあまりしないけど取りまとめを行う管理職みたいな奴です。
Q-1-5. Modelってなんですか？
A. Controllerから渡されたデータを使ってデータベースからデータを取ってきたり、
取ってきたデータを計算したり、Viewが扱いやすいように加工したりする奴らです。
データベースにアクセスする奴をDaoとかRepositoryと呼び、
Dao/Repositoryの呼び出しや、計算や加工をする奴をビジネスロジックと読んで、さらに細かく役割を分ける場合もあります。
（というかほとんどの場合そうします）
Q-1-6. MVCフレームワークを使うと何がいいんですか？
A. 上記にも書いてある通り、役割と依存関係の明確化です。
Q-1-6-1. 役割の明確化って具体的には？
A. 上記にもある通り、View、Controller、Modelと役割を分割できます。
また、Controllerに該当するクラスは「~~~~Controller」とか、
Daoに該当するクラスは「~~~~Dao」といった名前にすることで、クラスの名前を見るだけでどんな機能を持っているかある程度知ることができます。
Q-1-6-1-1. どんな機能を持っているかって、自分で作るからそもそもわかってるんですけど？
A. 自分で作ってなかったら？
チームでの開発なのでどの機能はだれだれが担当する、といった具合に役割分担をします。
他の人が作ったクラスを使うこともあるのでそういった場合に名前から機能を判別出来たら便利ですよね。
Q-1-6-2. 依存関係の明確化って？
A. 上記にも書いた通りModelやViewはControllerからしか呼ばれません。
例えば、あるModelのクラスを修正するとき、そのクラスを呼び出している他のクラスに影響がないか調べる必要があります。
この時、依存関係が明確化されていれば、Controllerからしか呼ばれないことがわかるので、Controllerのみ調べればよい、ということがわかります。
どこに影響があるかわからず、ViewやModelの他クラスを調査する、なんて手間が省けるということです。
Q-2. そもそもフレームワークってなんですか？
A. 複数の意味があります。
①「MVCフレームワーク」のフレームワーク
アーキテクチャとほぼ同じ意味です。デザインパターンと呼んだりもします。
開発をやりやすくするための決まり事ですね。
②「ASP.NET Core MVC フレームワーク」のフレームワーク
①のフレームワークを実現するのをいろいろサポートしてくれるライブラリ群のことをいいます。
①は決まり事という概念。②は①を実現したプログラムということです。
Q-3. ASP.NET Coreってなんですか？
A. C#でWebアプリケーションを作るためのフレームワークです。
ASP.NET Core MVCはASP.NET Coreの機能を使って作ったまた別のフレームワークです。
別のフレームワークといっても、ASP.NET Coreの機能がないとASP.NET Core MVCは動きませんので、
ASP.NET Core MVCを使うということはASP.NET Coreも使うことになります。
.NET Core上で動きます。
Q-3-1. .NET Coreってなんですか？
A. C#でアプリケーションを作るためのフレームワークです。
いろいろ便利な機能が詰め込んである汎用的なフレームワークですね。
元々は.NET Frameworkという名前のフレームワークが広く使われていたんですが、数年前にクロスプラットフォーム版.NET Frameworkとして.NET Coreという新しいフレームワークが開発されました。
.NET FrameworkはWindows上でしか動きませんが、.NET Coreは他OSでも動きます。
Q-3-2. .NET Standardという名前を見るんですが、これはなんですか？
A. .NET Frameworkとか.NET Coreなどのフレームワークをまとめて.NET実装、と呼びます。
.NET Standardは.NET実装の仕様、という位置づけになります。
これだけではわからないと思うので具体的に説明すると、
Microsoftが汎用的なフレームワークをいろいろ作っています。
いろいろ作っている複数のフレームワークには共通の決まりごとがあります。
・リストの機能を実装しなければならない
・ジェネリクスの機能を実装しなければならない
・I/Oの機能を実装しなければならない
etc・・・
この決まりごと（=仕様）のことを.NET Standardと呼び、この決まりごとに従って開発されたフレームワークを.NET実装と呼びます。
.NET実装は他には「Mono & Xamarin」なんていう「.NET」がついてないものもあります。
もともとMicrosoft製ではありませんでしたが、Xamarin社が買収されて今はMicrosoftが管理しています。
Q-4. EntityFrameworkってなんですか？
A. データベースにアクセスするためのフレームワークです。
コードファーストをサポートしています。
ちなみにEntityFrameworkは.NET Framework用のライブラリで、
EntityFrameworkCoreは.NET Core用のライブラリになっています。
なので今回実際に使用するライブラリはEntityFrameworkCoreですね。
Q-4-1. コードファーストってなんですか？
A. POCOからデータベースを自動生成する開発スタイルのことです。
また、レコードの追加・更新や検索もC#で全て行うことができます。
EntityFrameworkはPOCOの定義からテーブルを作成し、C#のオブジェクトが変更されたらDBのレコードも自動で変更する、という機能を持っています。
逆に最初にデータベースのテーブル定義を考えて、それに合わせてコーディングしていくスタイルをデータベースファーストと呼びます。
Q-4-1-1. POCOってなんですか？
A. メソッドを持たず、プロパティだけ持つ、データを格納するだけが目的のクラスのことです。
Q-4-1-2. コードファーストだと何がいいんですか？
A. C#だけでデータアクセスが完結し、SQLを書く必要がありません。
また、SQLで取ってきたデータをC#のオブジェクトに変換する処理（O/Rマッピング）が必要なくなります。
Q-4-1-3. じゃあコードファーストだけ使っていればいいんですか？
A. 既存のシステムでも長年動いてフレームワークが古くなってきたから新しいフレームワークを選定する。という時があります。
そういったシステムは既にデータベースが存在する場合が多く、EntityFrameworkを使おうとするとデータベースに合わせてPOCOの定義を作成する必要が出てきます。
その過程でバグが仕込まれてしまうかもしれないし、動作実績があるSQLが既に存在するのでそれを使う方が新たなバグを仕込んでしまう可能性は低いといえます。
この場合はコードファーストを採用する方がリスクが高いですね。
また、コードファーストはあまり速度が速くないのであまりにも大きいデータを扱う場合は不向きです。
更に、C#では行えず、SQLでしか行えない操作というのもあります。そういった操作を多く使う場合はデータベースファーストのほうがよいでしょう。
Q-4-2. ASP.NETってASP.NET Coreとは違うんですか？
A. 違います。ASP.NETは.NET Framework上でのみ動くフレームワークですが、
ASP.NET Coreは.NET Standard上で動くフレームワークです。
.NET Standard上で動くということは.NET Frameworkでも.NET Coreでも動くということですね。
要はASP.NETの方が古いということです。
Q-4-2-1. 古いのにまだASP.NETを使おうという記事をよく見ますが、何故ですか？
A. ASP.NET Coreは新しいので、ASP.NETに比べて採用例が少ないからです。
Web上の情報もまだ多くありませんし、使われている期間が短く十分に洗い出されていないため、
致命的なバグが埋め込まれている可能性が否定できないためです。
ASP.NETは昔からあるフレームワークなので、その点でいうと安心です。
また、ASP.NET Coreは余分な機能をなくしてシンプルになっているので、ASP.NETにはあるけどCoreにはない機能も存在します。
ただ、「ASP.NETを使おう」という記事自体が古い可能性があるので注意してください。
ネットや本から情報を得るときは、記事の日付や出版年月日を確認してください。
Q-4-2-2. じゃあASP.NET Coreは使わないほうがいいんじゃないですか？
A. そんなことはないです。古いフレームワークはサポート終了がより近いです。サポートが終了されると、そのフレームワークに致命的なバグがあったとしても修正されません。新しいバージョンに移行しろ、と言われます。
更に、新しいフレームワークの方が新しい機能が追加される速度が速いというところもあります。
また、上記の通りASP.NET Coreはシンプルです。煩雑な設定などがすっきりしているので開発しやすいという点もあります。
新しいフレームワークがイケてなくてすぐに廃れてしまう、という可能性もありますが、
個人的には、既に普及している「ASP.NET」の名前も冠していてMicrosoftが今後押していく姿勢も見せていますし、クロスプラットフォーム対応で応用も効くので、将来性という点ではASP.NET Coreの方が良いと思っています。
他にも説明するべき事柄が思いついたら追記します。