94. ASP.NET Core × Entity Framework

前回の記事　　　　　　　　　　　　　　　　　　　　　　　　次回の記事

はじめに

前回、EntityFrameworkCore を SQL Server に対して適用してみました。SQLite はローカルのファイル形式のデータベースであり複数ユーザーからの同時利用はできませんでしたが、本格的なサーバー形式の SQL Server ならそれが可能です。今回は、サーバー形式で運用されているリレーショナルデータベース（SQL Server）を、Web サービスとして公開する方法を、ASP.NET Core を使って試してみることにします。

参考にするチュートリアル

今回参考にするのは、
チュートリアル: ASP.NET MVC Web アプリでの EF Core の概要 | Microsoft Learn 
です。Visual Studio 2022 を使って開発を行います。いつもと同様、全て、するっと書いてある通りで動けば、全て無料公開しようと思ったのですが、未記載の様々なポイントが満載なので、途中から有料記事とすることとします。

アーキテクチャ

構成要素が結構多いので、一応全体のアーキテクチャを解説してから作業を進めることにします。今回使用する、ASP.NET MVC Web アプリプロジェクトは、名前の通り、MVC（Model View Controller）アーキテクチャを採用した Web アプリケーションを作成するためのプロジェクトです。

• Model → ビジネスで扱うデータモデル。SQL Server 上のリレーショナルデータベースで実装

• View → ユーザー向けの UI を提供する表示の仕組み。今回は HTML 等で実装された Web ページ

• Controller → View と Model の仲介

という、ビジネスアプリケーションでは昔からの常道アーキテクチャです。なんでこんな構成をとるかというと、こうしておけば、View と Model の依存性を低くできるからです。もちろん、Model に変更があれば、UI で表示する項目が変わるので、View も当然影響を受けるのですが、あるビジネスに対してある程度ちゃんと設計されたスキーマを元にして Model が実装されていれば、そうそう変わるものではありません（変わるのはビジネスモデルに変更がある時だけ）。単にユーザー向けの操作性を改善したいとか、データモデルが変わらない処理フローやプロセスの変更だけならば、Model や Controller に一切、修正を生じることなく、View の改変ができます。

MVC アーキテクチャと実装技術

※ Controller に変更が生じないのは、Model にアクセスする API がしょせんは、CRUD（Create、Read、Update、Delete）というシンプルなものだからです。まぁ、処理フローやプロセスといったデータモデルを元にした振舞いもまた、ビジネスモデルの一部ではあるのですが、そちらはまた別のお話ということで、ここでは流すことにします。

加えて、Web アプリケーションの場合、View は HTML 系、Model は RDB（NoSQL や Vector DBでも可）系、Controller は Web サーバーのミドルウェア（今回は、ASP.NET Core） と、実装技術の系統が全く異なり、切り離されているがゆえに、それぞれで独立して実装技術の選択、そして、それを使った実装・運用ができるようになっています。

データモデル

さて、このチュートリアルで扱うデータモデルですが、

https://learn.microsoft.com/ja-jp/aspnet/core/data/ef-mvc/intro/_static/data-model-diagram.png?view=aspnetcore-8.0

という、学校が提供するコースと、学生のコース受講の状態を保持するようになっています。私は、概念モデリングの専門家なので、”Art of Conceptual Modeling” で解説している表記に直すことにします。

Conceptual Information Model の表記で書いたデータモデル

今回のモデルは、Enrollment から見て、CourseとStudent の両側の多重度が、”1” になっているので、どちらのデータモデルも、そのスキーマに従って、概念インスタンス（SQL の場合は レコード）を構成してもどちらも同じ状態を記述できるようになっています。まぁ、本質的な話をすると、Enrollment という Relationship 自体が概念項目なので、下の図の方がより、正しく対象世界（意味の場）を表現しているかなと（自画自賛ｗ）。

このデータモデルをそのまま使おうと当初は思っていたのですが、思い直して、多重度が同じだけど意味の違うデータモデルを使うことにしました。

今回のお試しで想定するデータモデル（Conceptual Information Model）

Drug（薬）の製造を行う製薬会社に関する簡単なモデルです。Equipment は製造装置を指します。Drug は、ドラッグストアで規定数の錠剤が箱に梱包されて売られているものを想像してください。Drug という概念クラスの概念インスタンスは、それぞれ、その箱を指すものとします。その箱ごとに SerialNo がついていて、それぞれの Drug（錠剤が梱包された箱）が区別できるようになっています。その Drug に梱包されている錠剤は、幾つか複数の製造装置（Equipment）で、それぞれ、材料から、砕かれたり、混ぜられたり、熱せられたりして製造されるものとします。製薬工場に、それぞれの Drug の種類ごとに、複数の製造装置（Equipment）が並んだ、製造ラインがあり、そのラインの順番で薬が製造されていくという訳です。更に、その製造ラインは、ビジネスの計画に従って、組みなおされて新たな製造ラインが設置されて、別の巣類の薬が作られたりもします。その際、製造装置（Equipment）は再利用されることを想定しています。もし、それぞれの製造装置に不具合、例えば、カビが生えていた、とか、何らかの不良があった場合、その装置で作成された Drug にも何らかの不具合があると考えなければならないので、回収しなければならないと。そういうことで、Processed という概念クラスで、Drug の製造に関与した Equipment の情報を管理したい、という訳です。
説明が長くて申し訳ないですが、図で書いている内容を言葉で説明すると、こんなに長い文章になるということの例としてご了承くださいませ。

元のチュートリアルのデータモデルの解説文を読むと、Course、Enrollment、Student 以外にも、その Course を提供している School とか、それらを担当する講師とか、色々書いてありますね。それと同様に、私のモデルも、説明文の中に概念情報モデルでは表現されていない概念が幾つか存在してしまっています。参考までに、最低限必要と思われる概念群を追加したモデルを紹介しておくことにします。

最低限必要そうな概念を追加した Conceptual Information Model

皆さん、それぞれで読み解いてみてくださいね。

移行、Drug、Equipment、Processed の3つの概念クラスのモデルで話を進めることにします。

一通り基礎の部分の説明が終わったので、早速サンプルを作成していくことにします。

ASP.NET Core Web MVC プロジェクトの作成と下準備

Visual Studio 2022 を起動して、新しくプロジェクトを作成します。プロジェクトテンプレートは、ASP.NET Core Web MVC（Model-View-Controller）です。名前は、WebAppEFCore としました。