第31章　まとめ:Windowsフォーム vs Web の比較

この章の目的

この章は 読み返しと振り返りの章 です。新しいコードはほとんど書きません。

第 18〜25 章で Windows フォーム、第 26〜30 章で Web(ASP.NET Core MVC) という 2 つのプラットフォームを通り抜けてきました。途中、第 23〜25 章と第 28〜30 章では、まったく同じ「社員管理アプリ」を 2 度作り直す という回り道をしました。

「同じ題材を 2 通りで作る」のは、研修としては時間がかかるやり方です。それでもこの構成にしているのは、

どちらか一方を学ぶより、比べて初めて見えてくる構造 がある
配属先のチームで「逆側」を任されたとき、最初に何を確認すればよいか分かる
新人のうちに「プラットフォームに依存しない部分(SQL、業務ロジック、Repository)」と「プラットフォームに依存する部分(画面・操作・状態)」を切り分けて見られるようになってほしい

という狙いがあるからです。

本章では、これまでの章を 観点ごとに横並びで整理 し、自分の中で「Windows フォームとは何だったか」「Web とは何だったか」「次にやるならどちらか」を言葉にできる状態を目指します。

この章でできるようになること

この章を終えると、次のことができるようになります。

Windows フォームと Web MVC の 画面・操作・状態管理 の違いを自分の言葉で説明できる
「Repository より上の層は別物、Repository より下は同じ」という分離を意識して設計を読める
Windows 統合認証と SQL 認証の使い分けを業務シーンと結び付けて説明できる
イベント駆動とリクエスト駆動の違い、PRG パターンが Web で必要な理由を説明できる
業務カテゴリに対して「Windows フォーム向き」「Web 向き」のどちらを薦めるか、根拠を持って判断できる
自分が次に深掘りすべきテーマ(配属先の技術スタックに応じて)を選び取れる

本章で使用する環境

項目	内容
必要なもの	第 23〜25 章 / 第 28〜30 章の手元コード(または Git に提出済みのもの)
推奨	Visual Studio 2022 で両ソリューションを開けると比較しやすい
提出物	レポート(Markdown、テキスト、ノート、Word ── いずれも可)

この章はコードを実装しません。読み返しと議論、レポート作成が中心です。

31-1　ここまで作ってきたもの

最初に、第 18 章以降で何を作ってきたかを 同じ業務目線 で並べてみます。

章と成果物の対応

章	プラットフォーム	成果物	主な学習テーマ
第 18 章	Windows フォーム	環境準備	プロジェクト作成、フォームデザイナ
第 19 章	Windows フォーム	入門アプリ	コントロール配置、イベントハンドラ
第 20 章	Windows フォーム	タイマーアプリ	`Timer` コントロール、イベント駆動
第 21 章	Windows フォーム	デバッグ操作	ブレークポイント、ステップ実行
第 22 章	Windows フォーム	CSV 読み書き	`StreamReader`、`DataGridView`
第 23 章	Windows フォーム	社員一覧	Repository、`SqlDataReader`、JOIN
第 24 章	Windows フォーム	社員検索	`SqlParameter`、SQL インジェクション
第 25 章	Windows フォーム	社員 CRUD	モーダル、`DialogResult`、PRG なし
第 26 章	Web MVC	占いアプリ	MVC の流れ、Model Binding、Razor
第 27 章	Web MVC	部署一覧	SQL 認証、Repository、DI なし方針
第 28 章	Web MVC	Web 社員一覧	`@foreach`、ViewModel、disabled 枠
第 29 章	Web MVC	Web 社員検索	クエリ文字列、`<select>` の状態復元
第 30 章	Web MVC	Web 社員 CRUD	ルーティング、PRG、`ModelState`

太字の 6 章(第 23〜25 章と第 28〜30 章)は 完全に同じ業務(社員管理 CRUD) を 2 通りの技術で作っています。これが本章の比較対象です。

「同じ業務」だからこそ見えるもの

両者は次のように対応しています。

業務上の機能	Windows 版	Web 版
社員一覧表示	第 23 章 `Form1` + `DataGridView`	第 28 章 `EmployeesController.Index` + `Index.cshtml`
検索	第 24 章 `buttonSearch_Click` + `TextBox`/`ComboBox`	第 29 章 `Index(string keyword, int dept)` + `<form method="get">`
新規登録	第 25 章 `buttonNew_Click` → `EmployeeEditForm.ShowDialog()`	第 30 章 `Create` (GET/POST) + `Create.cshtml`
編集	第 25 章 `buttonEdit_Click` → `EmployeeEditForm.ShowDialog(target)`	第 30 章 `Edit/{id}` (GET/POST) + `Edit.cshtml`
削除	第 25 章 `buttonDelete_Click` + `MessageBox` 確認	第 30 章 `Delete/{id}` (POST) + `confirm()`
DB アクセス(Repository)	`EmployeeRepository` / `DepartmentRepository`	`EmployeeRepository` / `DepartmentRepository`

Repository だけは、ほぼコピーで動く という事実が、ここまでの 6 章での最大の発見です。この章ではこの「コピーで動く部分と、書き直す部分」の境界線を、観点ごとに整理していきます。

31-2　観点1:画面の作り方

観点	Windows フォーム	Web MVC
画面の正体	1 つの `Form` クラス(`.cs` + `.Designer.cs` + `.resx`)	1 つの `.cshtml`(View)+ レイアウト
画面の作り方	デザイナで GUI ドラッグ&ドロップ	HTML を Razor で書く
コントロール	`Button` / `TextBox` / `ComboBox` / `DataGridView`	`<button>` / `<input>` / `<select>` / `<table>`
値と画面の結び付き	`textBoxKeyword.Text` のようにプロパティで読み書き	`<input asp-for="Keyword">` で Model のプロパティ名と紐づく
一覧表示	`DataGridView.DataSource = list;`(自動描画)	`@foreach (var e in Model.Results) { <tr>...</tr> }`(自分で書く)
スタイル	Windows の見た目に従う(`Font`、`Size`)	CSS(Bootstrap 等)で自由

コード比較:検索フォームの組み立て

Windows 版(デザイナで配置 → C# でアクセス)

// デザイナで TextBox、ComboBox、Button を貼り付ける
private void buttonSearch_Click(object sender, EventArgs e)
{
    string keyword = textBoxKeyword.Text.Trim();
    int departmentId = (int)comboBoxDepartment.SelectedValue;
    List<Employee> list = _employeeRepository.Search(keyword, departmentId);
    dataGridViewEmployees.DataSource = list;
}

Web 版(HTML を Razor で記述)

<form method="get" asp-action="Index">
    <input asp-for="Keyword" />
    <select asp-for="DepartmentId">
        @foreach (var d in Model.Departments) { <option value="@d.DepartmentId">@d.DepartmentName</option> }
    </select>
    <button type="submit">検索</button>
</form>

public IActionResult Index(string keyword, int departmentId)
{
    var list = _employeeRepository.Search(keyword ?? "", departmentId);
    // ViewModel に詰めて View に渡す
}

何が違うか

Windows は 「画面を作る」=「デザイナで貼る」。コントロールは C# の オブジェクト として存在し、プロパティで状態を読み書きする。
Web は 「画面を作る」=「HTML を組み立てる」。<input asp-for> のように Razor のタグヘルパー が C# のプロパティと HTML の name/value を橋渡しする。

Windows では、画面に並べたコントロールが C# の世界の中 にいます。Web では、画面は ブラウザに送り出された HTML なので、C# の世界からは「もう手の届かない場所」にあります。だから、値のやり取りは毎回 POST / GET の引数 という形を取ります。

31-3　観点2:ユーザー操作の捉え方(イベント vs リクエスト)

観点	Windows フォーム	Web MVC
操作の最小単位	イベント(クリック、入力、フォーカス移動 …)	HTTP リクエスト(GET / POST)
駆動モデル	イベント駆動	リクエスト/レスポンス駆動
「ボタンを押す」=何が起きるか	同じプロセス内で `Click` イベントが発火	ブラウザがサーバーに POST を送り、サーバーが新しい HTML を返す
同じ画面の再表示	コントロールはそのまま残る	HTML を毎回送り直す
ユーザー入力の中断	フォームを閉じれば消える	リクエスト中はサーバーが待つ、間で閉じられたら捨てるだけ

コード比較:「保存」ボタンの動き

Windows 版

private void buttonSave_Click(object sender, EventArgs e)
{
    // 同じプロセス内。validateして、Insert/Update して、ダイアログを閉じる。
    if (!ValidateInput(out string error)) { MessageBox.Show(error); return; }
    _employeeRepository.Update(employee);
    // DialogResult = OK で閉じる(呼び出し元が一覧を再描画)
}

Web 版

[HttpPost]
public IActionResult Edit(int id, EmployeeEditViewModel model)
{
    ValidateEmployeeInput(model);
    if (!ModelState.IsValid) { return View(model); } // エラー時は画面を返す
    _employeeRepository.Update(...);
    return RedirectToAction("Index"); // 一覧に GET でリダイレクト(PRG)
}

何が違うか

Windows の buttonSave_Click は、押された瞬間に 同じプロセス・同じメモリ空間で すぐ実行されます。コントロールも変数もそこにあるので、終わったら次の処理に移るだけです。

Web の Edit (POST) は、ブラウザから飛んできた 1 回限りの HTTP リクエスト に対する応答です。処理が終わると、Controller は 何かを返さなければなりません(View、Redirect、404 など)。返した瞬間にすべての変数は消え、次のリクエストはまたゼロから始まります。

この違いが Web の以下のクセに直結します。

PRG パターン(第 30 章 30-6):保存後に View を返すと F5 で二重送信される
状態は毎回引き渡す(次節):画面間で勝手に値が残らない
削除は POST で送る(第 30 章 30-10):URL を踏ませる GET は意図せず実行される

31-4　観点3:状態の保持(画面間で値をどう持つか)

「いま誰を編集しているのか」をどこに保持するかが、両者で大きく違います。

観点	Windows フォーム	Web MVC
現在の画面状態	フォームのフィールド・コントロールがそのまま保持	リクエストが終わると消える
編集対象の渡し方	`new EmployeeEditForm(repo, repo, target: selected)` でオブジェクト参照を渡す	URL `/Employees/Edit/1001` で ID だけ渡す
編集中の入力値	コントロールに残る(画面を閉じない限り)	リクエストごとに POST で送り直す
検索条件の保持	フィールド変数で保持(`Form1` が生きている限り)	クエリ文字列に乗せて毎回送る
グローバルな共有	`static` フィールドや DI コンテナ	`Session`(本研修では未使用)、`TempData`、Cookie
多人数で同じデータを編集	アプリ起動者 1 人のみ(同時編集の概念なし)	同時編集が前提(楽観/悲観ロックなどの考慮)

コード比較:編集対象を渡す

Windows 版

private void buttonEdit_Click(object sender, EventArgs e)
{
    Employee selected = GetSelectedEmployee(); // ← 既に Employee オブジェクトを持っている
    using EmployeeEditForm dialog = new EmployeeEditForm(_employeeRepository, _departmentRepository, target: selected);
    dialog.ShowDialog(this); // ← オブジェクト参照ごと渡せる
}

Web 版

<a asp-action="Edit" asp-route-id="@emp.EmployeeId">編集</a>
@* ↑ URL に ID だけ載せる。/Employees/Edit/1001 *@

[HttpGet]
public IActionResult Edit(int id)
{
    Employee employee = _employeeRepository.GetById(id); // ← もう一度 DB から取り直す
    // ViewModel に詰めて View に渡す
}

何が違うか

Windows では Employee オブジェクトを そのまま 別フォームに渡せます。同じプロセスで動いているので、参照を共有できるからです。

Web では、画面遷移の合間に C# のオブジェクトはすべて消えてなくなります。次のリクエストで必要なものは、URL のパラメータ(/Employees/Edit/1001)・hidden(<input type="hidden">)・POST のフォーム値・クエリ文字列のいずれかで 明示的に渡し直す 必要があります。

なぜ Web 版で GetById を呼び直すのか

一覧画面で取得した Employee を編集画面に「持ち回り」できないからです。一覧を表示したリクエストと、編集画面を開くリクエストは別のものなので、編集画面の Controller は「1001 番の社員を編集したい」という URL の情報だけを頼りに、もう一度 DB に問い合わせます。

31-5　観点4:Repository / DB アクセス層

ここがこの研修で 最も伝えたい一致点 です。

観点	Windows フォーム(第 25 章)	Web MVC(第 30 章)
クラス名	`EmployeeRepository`	`EmployeeRepository`
使う API	`SqlConnection` / `SqlCommand` / `SqlDataReader`	`SqlConnection` / `SqlCommand` / `SqlDataReader`
パラメータ化クエリ	`cmd.Parameters.AddWithValue(...)`	`cmd.Parameters.AddWithValue(...)`
`Insert` の中身	`INSERT ... OUTPUT INSERTED.employee_id`	`INSERT ... OUTPUT INSERTED.employee_id`(まったく同じ)
接続文字列の場所	`Form1` の `const string ConnectionString`	`EmployeeRepository` 内の `const string ConnectionString`(本研修方針)
認証方式	Windows 統合認証	SQL 認証(`User Id=app_user;Password=...`)
`DBNull.Value` の扱い	同じ	同じ
例外型	`SqlException`	`SqlException`

違うのは「接続文字列の中身」と「呼び出し元」だけ

第 30 章 30-2 で EmployeeRepository を実装したとき、第 25 章のコードと ほぼコピーで動いた ことを思い出してください。違ったのは:

namespace を Ch30_MvcEmployeeEdit.Data に変えた
接続文字列を Windows 統合認証から SQL 認証に変えた

の 2 点だけです。SQL も、SqlParameter の使い方も、OUTPUT INSERTED.column_name の発想も、ExecuteScalar / ExecuteReader / ExecuteNonQuery の使い分けも、すべて同じでした。

この意味:現場で何を再利用できるか

業務で「同じ Web アプリを Windows フォーム化したい」「逆に Windows フォームアプリを Web に作り直したい」と頼まれたとき、Repository とテーブル設計はそのまま生かせる ということです。作り直しが必要なのは、Controller / Form の上層と View 層です。

逆に言えば、Repository の設計が悪いと、両方とも巻き込まれて辛くなる。だから、第 23〜30 章で Repository パターンと SqlParameter を繰り返し練習したのです。

31-6　観点5:認証(誰として DB に繋ぐか)

観点	Windows フォーム(第 23〜25 章)	Web MVC(第 27〜30 章)
採用した認証	Windows 統合認証	SQL 認証(`app_user`)
接続文字列	`Integrated Security=true`	`User Id=app_user;Password=...`
誰として DB に繋ぐか	アプリを起動した Windows ユーザー	アプリ全体で 1 つの専用ユーザー
DB の権限管理単位	個人(Windows ログイン)	アプリ(専用ユーザー)
パスワード管理	不要(OS の認証を使う)	アプリ側で安全に保持(本来は appsettings + シークレット)

なぜ使い分けるのか

Windows フォームは「業務 PC の上で、その人が起動する」 前提のアプリです。そのため、起動した Windows ユーザーをそのまま DB のログインとして使えます。DB 側で「この Windows ユーザーには employees テーブルへの SELECT を許可」と権限管理ができ、アプリにパスワードを持たせる必要がありません。

Web MVC は「サーバー上で動いていて、複数のユーザーがブラウザでアクセスする」 前提のアプリです。ブラウザから来たユーザーが、どの Windows ユーザーか、サーバーから直接見える保証はありません(社外からアクセスされることもある)。だから、サーバーが「アプリ専用ユーザー」として 1 本の接続で DB に繋ぎ、利用者の認証はアプリ側で別途行う、というのが基本構成になります。

「Windows 統合認証を Web で使ってはいけないか?」

社内イントラ専用で Active Directory が整備されている環境では、Web でも Windows 統合認証(Kerberos 認証)を使う構成もあります。本研修では 基本パターンを掴むこと を優先して、Web は SQL 認証で統一しました。

31-7　観点6:同時利用とライフサイクル

観点	Windows フォーム	Web MVC
同時に動くアプリの数	ユーザーが起動した分だけ(自分の PC で 1 つが普通)	1 つのサーバーで多人数同時
プロセスのライフサイクル	起動 → 操作 → `[×]` で終了	サーバーは常時起動、リクエストごとに処理
変数・コントロールの寿命	アプリを閉じるまで残る	リクエスト処理が終わると消える
メモリ管理	起動者 1 人分	同時アクセス数 × リクエスト
DB の同時更新	「自分しか触らない」前提でも済む場面が多い	必ず「他の人が同じ行を編集中かも」を意識
デプロイ後の更新	各 PC に配り直す	サーバー側を入れ替えれば全員に反映

同時編集問題

Web では、ユーザー A が「1001 番の社員」を編集中に、ユーザー B が同じ社員を編集して先に保存することがあり得ます。A が後で保存ボタンを押すと、B の更新を 無自覚に上書きしてしまう ── これを 「最後の更新で勝ち」問題 と呼びます。

本研修ではこの問題には立ち入りませんでしたが、業務 Web アプリではよく以下のような対策を打ちます。

楽観ロック:行に「バージョン」列を持たせ、編集前と保存前で一致するか確認する
悲観ロック:編集開始時に行をロック(他の人は読めるが編集不可)
競合検出して画面でユーザーに選ばせる

Windows フォームでも DB を共有していれば同じ問題はあり得ますが、「自分の PC 上のアプリで自分の業務をこなす」用途では、競合確率が低く、対策が省略されがちです。

31-8　観点7:配布・デプロイ

観点	Windows フォーム	Web MVC
配布物	`.exe` + 必要な DLL(自己完結)	サーバー側のファイル一式(IIS / Kestrel など)
インストール先	各社員の PC	Web サーバー(社内 / クラウド)
利用者の準備	.NET ランタイムが入った PC	ブラウザだけ
バージョンアップ	全 PC に配り直す	サーバーを差し替えれば全員に届く
利用範囲	配った PC のみ	URL を知っていれば誰でも(認証で制御)
社外アクセス	基本的に困難	公開 URL にすれば容易
インストール失敗のリスク	各 PC で起こり得る	サーバー側で集中管理

この研修サイトはどちらの形か

このテキスト自体が Web アプリの実例 です。皆さんは ブラウザだけ で読めていて、内容が更新されても、各自が何かを入れ直す必要はありません(開いた URL を見れば、いつでも最新です)。もし「研修テキストアプリ.exe」を配って読む形だったら、テキスト更新のたびに全員に配り直す必要がありました。Web の利点は、ここでも効いています。

Windows フォームが選ばれる場面

社内 LAN 内の業務、社員 PC 上で動かす必要があるもの
ハードウェア(プリンタ、スキャナ、シリアルポート)を直接叩く業務
ローカルのファイルや Excel と密に連携する作業

社員配属先の Windows アプリケーション開発部署では、こうしたケースで Windows フォーム / WPF / WinUI が現役で使われています。

31-9　観点8:エラー・入力チェック・二重送信

観点	Windows フォーム(第 25 章)	Web MVC(第 30 章)
入力チェックの書き方	`ValidateInput(out string error)` で `MessageBox`	`ModelState.AddModelError` + `asp-validation-for`
エラーの見せ方	ポップアップ(`MessageBox`)	画面内のラベル(`<span class="text-danger">`)
入力値の保持	コントロールに残る(画面が閉じないので自然と残る)	`return View(model)` で値を返し直す
削除前の確認	`MessageBox.Show(..., MessageBoxButtons.OKCancel)`	`<form onsubmit="return confirm('...')">`
二重送信対策	不要(同じプロセスで完結し、F5 という概念がない)	PRG パターン必須(`RedirectToAction`)
DB の例外	`try-catch (SqlException)` + `MessageBox`	`try-catch` で 500 エラーまたはエラー画面

「Web ならではの落とし穴」

Windows では、MessageBox を消した瞬間にフォームは元の状態で残っており、ユーザーが入力した値も消えません。それが当たり前なので、改めて何かする必要はありません。

Web では、サーバー側で return View(model) と書かない限り、画面は更新されてしまい、入力値も消える可能性があります。これを 意識的に書く必要がある のが Web の難しさです。

PRG パターン、ModelState、削除を POST で送る、<input type="hidden"> で値を一緒に送る ── これらはすべて「リクエストが終わると C# の世界がリセットされる」ことへの対策、と捉えると一貫して理解できます。

31-10　どちらを選ぶか:業務カテゴリ別の判断軸

新人のうちは、自分でプラットフォームを選ぶ機会はあまりないかもしれません。それでも「先輩の判断はなぜそうなったのか」が読めるようになると、設計レビューに参加できます。

おおまかな向き不向き

業務の特徴	向いている	理由
社員 1 人ひとりの PC で集計・帳票印刷	Windows フォーム	プリンタ・Excel との連携、ローカルファイル
製造現場で機器のシリアル通信	Windows フォーム	OS の API、ハードウェア直接アクセス
全社員が同じデータを更新(社員管理、勤怠)	Web	同時利用、サーバー集中管理、ブラウザだけで使える
社外からも参照する(顧客ポータル)	Web	URL 配布、認証で範囲制御
即時性の高い UI(ドラッグ、リアルタイム描画)	Windows フォーム(または WPF / Web の SPA)	双方向のイベントが密、ブラウザでは凝った UI は技術選択が必要
試作・社内ツール・小さな集計	Windows フォーム	配布の手軽さ(`.exe` 1 つで動く)
部署をまたぐ共有データ	Web	同時編集、デプロイ一元化

判断軸を 3 つに絞ると

配布範囲:1 人の PC か、複数の PC か、社外も含むか
同時更新:同じデータを複数人が同時に触るか
環境依存:ハードウェア・OS の機能を使うか、ブラウザだけで足りるか

この 3 つで「Web 寄り / Windows 寄り」がだいたい決まります。あとは、組織の技術スタック(SQLServer メインなのか、Linux サーバーがあるのか、配属先がどちらに強いか)で最終判断します。

「ハイブリッド」もある

実際の現場では、

データ入力 → 社員 PC で Windows フォーム
集計・閲覧 → Web で全社公開

のように、同じ DB を 2 つのアプリで囲む構成もよくあります。第 31 章まで来た皆さんなら、Repository を共通化しつつ、上層をそれぞれの技術で作る という発想ができるはずです。

31-11　次に学ぶなら

第 31 章まで読み切った時点で、次に深掘りすべきテーマは配属先と関心によって分かれます。代表的な進路を挙げておきます。

Windows アプリ系を深掘りしたい人

テーマ	キーワード
現代的な Windows GUI フレームワーク	WPF、WinUI 3、MAUI
大規模アプリ向け設計パターン	MVVM、Prism
並行処理	`async / await`、`Task`、`Dispatcher`
インストーラ作成	MSIX、ClickOnce

Web 系を深掘りしたい人

テーマ	キーワード
MVC の発展形	Razor Pages、Minimal API
シングルページアプリ	Blazor、React + ASP.NET Core API
認証・認可	ASP.NET Core Identity、JWT、OAuth
設定と DI の本格運用	`appsettings.json`、Options パターン、依存性注入(第 27 章 27-11 の補足を本格化)

DB 設計を深掘りしたい人

テーマ	キーワード
クエリチューニング	実行計画、インデックス
トランザクション設計	楽観/悲観ロック、`SqlTransaction`、分離レベル
ORM	Entity Framework Core、Dapper

共通して効く「現場の基礎」

テーマ	キーワード
Git ブランチ運用	feature ブランチ、Pull Request、レビュー
テスト	xUnit、`Microsoft.Data.SqlClient` を絡めた統合テスト
設計と読みやすさ	リファクタリング、命名、SOLID 原則

何から始めるかは、配属先で先輩や上司に「次に学ぶならどれか」と相談して決めてください。研修で身に付けた「Repository / 入力チェック / SQL の安全な書き方」は、どの進路でも土台になります。

よくある誤解

誤解	実態
「Windows フォームは古い」	業務 PC 用アプリでは現役。WPF / WinUI と共に Windows GUI の選択肢として現役
「Web のほうが必ず難しい」	状態を毎回引き渡す思考に慣れれば、Windows の「いろいろなコントロールの状態」を相手にするより整理されている面もある
「同じ業務なら一方を作れば十分」	「現場 PC で打鍵 + 経営層がブラウザで閲覧」のように共存するケースも多い
「Repository は飾り」	Repository が無いと、UI コードに SQL が混ざり、Win → Web の移植も難しくなる(第 27 章で味わったとおり)
「DI コンテナを使わない第 27〜30 章は本格的でない」	DI は設計の選択肢の 1 つ。研修では「`new` で組み立てる素朴な形」をまず理解し、業務で必要になったら DI に切り替えられる前提
「Web は GET と POST 以外は使わない」	REST API では PUT / DELETE / PATCH も使う。本研修は MVC の Form 中心なので GET / POST に絞った
「Windows 統合認証のほうが安全」	用途次第。アプリの利用範囲が社内 PC に閉じているなら有効、Web で社外からも来るなら別の認証が必要

学んだことチェック

Windows フォームと Web MVC の「画面の正体」の違いを言葉で説明できる
イベント駆動とリクエスト駆動の違い、PRG パターンが Web で必要な理由を説明できる
Windows と Web で Repository がほぼコピーで動いた ことを思い出せる
Windows 統合認証と SQL 認証の使い分けを 1 例ずつ挙げられる
同時編集問題が Web で特に問題になりやすい理由を説明できる
業務カテゴリに対して「どちら向きか」を 3 つの判断軸で説明できる
配属先で「同じ業務を逆プラットフォームで作りたい」と言われたとき、何を最初に確認するか答えられる
自分が次に深掘りしたいテーマを 1 つ挙げられる

ペア確認

研修の進め方によっては、隣の人またはチーム内で説明確認を行います。

次の内容を、自分の言葉で説明してください。

「Repository より上は別物、Repository より下は同じ」という言い回しは、何を指していますか?
Web で RedirectToAction("Index") を返さずに View(model) を返すと何が起きますか?
Windows 版の _target = selected と、Web 版の /Employees/Edit/1001 は、それぞれ何をどう渡しているのですか?
Windows 統合認証を Web アプリで使わなかった理由を、社外ユーザーの存在に触れて説明してください。
「全社員に展開する勤怠管理アプリ」「製造ライン横の検査端末で動く帳票印刷アプリ」「外部顧客が自社情報を確認するポータル」── どれにどちらを選びますか?その根拠は?
第 23〜25 章の EmployeeRepository のコードを、第 28〜30 章にそのままコピーしたとき、何を直しましたか?
PRG パターンの「P・R・G」を 1 文ずつ説明し、なぜこの順序なのかを答えてください。
自分が「次に深掘りしたいテーマ」を 1 つ挙げ、その理由を 1 分で話してください。

演習課題

この章の課題は レポート 1 本(必須)+ 発展 1〜2 本 です。コードを書く章ではないため、提出物は Markdown / テキスト / Word / ノート写真 など形式自由とします。

ソリューションを作る必要はありません。1 ファイル(または 1 枚) にまとめて、Git に提出してください。

各課題の提出ファイル名(例):

課題	提出ファイル名
課題31-1	`Kadai31_01_Comparison.md`
課題31-2	`Kadai31_02_PlatformChoice.md`
課題31-3	`Kadai31_03_NextTheme.md`

必須課題

課題 31-1　Windows フォーム vs Web 比較レポート

第 30 章の課題 30-3 で予告したレポートを正式に提出します。ここまでの第 23〜25 章と第 28〜30 章を見比べて、自分の言葉で次の 5 観点 をまとめてください。

観点(必須)

Repository 層:Windows と Web で本質的に何が違いましたか?(違うところ / 同じところを両方挙げる)
画面の作り方:どんな技術・コード・ファイルでそれぞれ画面を作りましたか?
ユーザー操作の捉え方(イベント vs リクエスト):何が同じで、何が違いますか?
状態の保持(現在編集中の社員は誰か、検索条件は何か):それぞれどう実現していましたか?
もう一方のプラットフォーム で同じ社員管理アプリを作る指示が出たら、何を 最初に確認 し、何を そのまま流用 し、何を 書き直す ことになりますか?

形式

各観点 5〜10 行程度を目安に
「本文のここに書いてある」というコピペは避け、自分の言葉 で書く
必要なら本文・自分のコードから 1〜2 行のコード例を引用してよい

確認すること

5 観点それぞれを自分の言葉で書いた
「Repository は同じ、上層が違う」が伝わる構成になっている
「次にどちらかで作るときに最初に確認すること」を 1 つ以上挙げた

発展課題

課題 31-2　業務シーンに対するプラットフォーム選定

次の 3 つの業務シーン それぞれに対して、「Windows フォーム / Web のどちらを推すか」「その根拠は何か」「もう一方を選ぶならどんな条件のときか」を答えてください。

#	業務シーン
A	自社の倉庫で、出荷担当者がハンディ端末ではなく共有 PC から当日の出荷一覧を確認・チェックを付ける
B	自社の取引先(社外) に、月次の請求情報を見てもらう仕組み
C	製造ラインの検査機(専用 PC) で、検査結果を入力すると同じ PC のラベルプリンタからラベルを印刷

形式

各シーンに対して「結論」「根拠 3 つ」「逆の選択肢を選ぶ条件」を箇条書き
31-10 の「3 つの判断軸(配布範囲・同時更新・環境依存)」を使うと書きやすい

確認すること

3 シーンすべてに結論を書いた
「Repository は共通化できる」という観点を 1 箇所以上で言及した
自社・配属先の事例(知っているなら)を 1 つ以上引いた

課題 31-3　次に深掘りしたいテーマの選定

31-11「次に学ぶなら」の選択肢から、または自分で別のテーマを選び、今後 3 か月で取り組みたいテーマ 1 つ を決めてください。

書く内容

テーマ名(例:「Entity Framework Core」「Blazor」「ASP.NET Core Identity」)
なぜそれを選んだか(配属先・興味・スキル不足の自覚など)
第 23〜30 章のどの章の知識が 土台になりそうか(例:Repository を学んだから、EF Core の DbContext との対比で読める)
最初の 1 か月で 何をどこまで やるか(本を 1 冊、写経で動くものを 1 個、など具体的に)

確認すること

テーマを 1 つに絞った
「第 ?? 章の知識が土台になる」と具体的な章番号を 1 つ以上挙げた
「最初の 1 か月」の目標が 計測できる形 で書かれている(冊数、アプリ数、章数、など)

提出前チェックリスト

課題 31-1(必須)を提出するファイルが用意できている
各観点を自分の言葉で書いた(本文のコピペになっていない)
レポート内に 1 つは 具体的な章番号 or コード断片 が引用されている
発展課題を提出する場合、課題ごとに別ファイルにしている
文字化けせず、コミット時のエンコーディングは UTF-8

Git への提出

第 31 章はソースコードの提出はありませんが、レポートを Git で提出します。

git status
git add Kadai31_01_Comparison.md
git commit -m "第31章 まとめ:Windowsフォーム vs Web の比較 レポート"
git push

Git の詳しい操作は、付録 C「Git のインストールと提出ルール」 を参照してください。

この章のまとめ

第 18〜25 章(Windows フォーム)と第 26〜30 章(Web)で、同じ社員管理アプリを 2 度作り直した 経験を、観点別に整理した
Repository より下(SQL・DB アクセス)は同じ、Repository より上(画面・操作・状態)は別物 が中心メッセージ
Windows は イベント駆動、Web は リクエスト駆動。この違いから PRG パターン・状態の引き渡し・削除を POST で送る、などの Web のお作法が一貫して説明できる
認証(Windows 統合 vs SQL)、同時利用、配布・デプロイ ── どれも「誰がどの PC で使うか」という前提の違いから来ている
業務カテゴリに対する「どちら向きか」は、配布範囲・同時更新・環境依存 の 3 つで判断できる
次に学ぶテーマは配属先と興味で分かれるが、本研修で身に付けた Repository / SqlParameter / 入力チェック はどの道でも土台になる

おわりに

第 0 章でコンソールに「こんにちは」と表示するところから始まり、最終的には 同じ業務アプリを Windows と Web の 2 通りで作り上げ、両者を比較して語れるところまで たどり着きました。

ここまでで学んだのは「C# の文法」だけではありません。

クラス・継承・インターフェイス といったオブジェクト指向の考え方
SqlParameter を使わなければ SQL インジェクションが起きる ようなセキュリティの基礎
Repository パターン で UI と DB を切り離す設計
PRG パターン や ModelState バリデーション など Web 特有のお作法
「同じ業務を 2 通りで書いてみて比較する」というプロを育てる思考法

配属先で待っているのは、研修よりずっと大きく複雑なコードベースです。それでも、「この層は何のためにあるのか」「この using は何を解放しているのか」「この SQL はパラメータ化されているか」を 読める目 が、ここで身に付いたはずです。

何か困ったら、テキストに戻ってきてください。研修サイトはあなたが現場に出てからも、localhost ではなくインターネットの向こうに、ずっと残っています。

お疲れさまでした。

第31章 まとめ:Windowsフォーム vs Web の比較

この章の目的

この章でできるようになること

本章で使用する環境

31-1 ここまで作ってきたもの

章と成果物の対応

「同じ業務」だからこそ見えるもの

31-2 観点1:画面の作り方

コード比較:検索フォームの組み立て

何が違うか

31-3 観点2:ユーザー操作の捉え方(イベント vs リクエスト)

コード比較:「保存」ボタンの動き

何が違うか

31-4 観点3:状態の保持(画面間で値をどう持つか)

コード比較:編集対象を渡す

何が違うか

31-5 観点4:Repository / DB アクセス層

違うのは「接続文字列の中身」と「呼び出し元」だけ

この意味:現場で何を再利用できるか

31-6 観点5:認証(誰として DB に繋ぐか)

なぜ使い分けるのか

「Windows 統合認証を Web で使ってはいけないか?」

31-7 観点6:同時利用とライフサイクル

同時編集問題

31-8 観点7:配布・デプロイ

この研修サイトはどちらの形か

Windows フォームが選ばれる場面

31-9 観点8:エラー・入力チェック・二重送信

「Web ならではの落とし穴」

31-10 どちらを選ぶか:業務カテゴリ別の判断軸

おおまかな向き不向き

判断軸を 3 つに絞ると

「ハイブリッド」もある

31-11 次に学ぶなら

Windows アプリ系を深掘りしたい人

Web 系を深掘りしたい人

DB 設計を深掘りしたい人

共通して効く「現場の基礎」

よくある誤解

学んだことチェック

ペア確認

演習課題

必須課題

課題 31-1 Windows フォーム vs Web 比較レポート

発展課題

課題 31-2 業務シーンに対するプラットフォーム選定

課題 31-3 次に深掘りしたいテーマの選定

提出前チェックリスト

Git への提出

この章のまとめ

おわりに

第31章　まとめ:Windowsフォーム vs Web の比較

31-1　ここまで作ってきたもの

31-2　観点1:画面の作り方

31-3　観点2:ユーザー操作の捉え方(イベント vs リクエスト)

31-4　観点3:状態の保持(画面間で値をどう持つか)

31-5　観点4:Repository / DB アクセス層

31-6　観点5:認証(誰として DB に繋ぐか)

31-7　観点6:同時利用とライフサイクル

31-8　観点7:配布・デプロイ

31-9　観点8:エラー・入力チェック・二重送信

31-10　どちらを選ぶか:業務カテゴリ別の判断軸

31-11　次に学ぶなら

課題 31-1　Windows フォーム vs Web 比較レポート

課題 31-2　業務シーンに対するプラットフォーム選定

課題 31-3　次に深掘りしたいテーマの選定