| 回 | 主題 | コマシラバス項目 | 内容 | 教材・教具 |
|
1
|
システムアーキテクチャ史
|
科目の中での位置付け
|
本講義は、Webアプリケーション開発演習（Spring Framework）の導入となる第1回目であり、Web開発の基礎となる理論的背景を確立する重要な位置付けにある。学生はJavaやHTMLの基礎知識を有しているが、それらが実際のWebシステムの中でどのように連携し動作しているかという全体像を把握していない場合が多い。本コマでは、Webアプリケーションの基本構造、通信プロトコル、およびサーバー構成といった不可欠な前提知識を体系的に整理し、次回以降に学ぶ具体的な技術変遷やフレームワークの必要性を理解するための強固な土台を構築する。
|
|
|
コマ主題細目
|
① Webアプリケーションとクライアント・サーバーモデルの概念 ② HTTP通信の仕組みとリクエスト・レスポンスの挙動 ③ Webシステムの3層構造とサーバーの役割分担
|
|
細目レベル
|
① 本主題では、Webアプリケーション開発の基礎となる「クライアント」と「サーバー」の関係性、および「アプリケーション」と「Webアプリケーション」の定義的な違いについて、テキストに基づき詳細に解説を行う。まず、一般的な「アプリケーション」がプログラミング言語で作成されたソフトウェア全般を指すのに対し、「Webアプリケーション」はインターネットを介して利用される点に本質的な特徴があることを提示する。具体的には、検索エンジンや通販サイト、e-ラーニングシステムなど、学生が日常的に利用しているサービスを例に挙げ、これらがWebアプリケーションであることを認識させる。その上で、これらのサービスが成立するための基本構造である「クライアント・サーバーモデル」について詳説する。クライアントとは「サービスを受ける側」であり、主にWebブラウザなどがその役割を担うこと、対してサーバーとは「サービスを提供する側」であることを定義し、両者の役割分担を明確にする。特に、サーバー側の重要な構成要素である「APサーバー（アプリケーションサーバー）」について、Webアプリケーションを配置し、クライアントからのアクセスを常時待ち続けるという特性を強調して解説する。授業の進行においては、テキストに記載されたクライアントとサーバーの関係図を用いながら、ブラウザからインターネットを経由してWebアプリケーションにアクセスするデータの流れを視覚的に説明する。また、単に用語を暗記させるのではなく、学生自身が普段利用しているブラウザが「クライアント」として機能し、遠隔地にある「サーバー」からサービスの提供を受けているという実感を伴った理解を促す。さらに、APサーバーが常時稼働していることの重要性や、リクエストを待ち受けるという受動的な振る舞いについても言及し、Webシステムの静的および動的な側面の双方からアプローチする。この過程を通じて、学生はWebアプリケーションが単なる画面の表示ではなく、ネットワークを介した双方向のやり取りによって成立しているシステムであることを深く理解することになる。この細目で理解すべき範囲は、Webアプリケーションの定義、クライアントとサーバーの基本的な役割関係、およびAPサーバーの機能まで。
|
② 本主題では、Webアプリケーションにおけるデータ送受信の基盤となる「HTTP通信」のメカニズムについて、プロトコルの概念から具体的なメソッドの違いに至るまで詳細に解説する。まず、HTTP（HyperText Transfer Protocol）がインターネット上で情報を送受信するための共通ルール（プロトコル）であることを定義し、クライアントとAPサーバー間で行われる「キャッチボール」のようなやり取り、すなわち「HTTPリクエスト」と「HTTPレスポンス」の往復によってWebページが表示されるプロセスを体系的に説明する。具体的には、ユーザーがブラウザにURLを入力した瞬間から、リクエストが送信され、サーバーがそれを処理してレスポンスを返し、最終的にブラウザが結果を表示するまでの一連の流れを、テキストのフロー図を参照しながら段階的に追跡する。次に、HTTPリクエストの主要なメソッドである「GETメソッド」と「POSTメソッド」について、その技術的な違いと使い分けの重要性を詳説する。GETメソッドは主に指定したURLの内容を「取得」するために用いられ、送信する値がURLの末尾に「クエリストリング」として付加される特徴を持つことを説明する。これに対し、POSTメソッドは入力情報を「送信」するために用いられ、データが「リクエストボディ」というURLには表示されない場所に格納される点を対比させる。この違いを理解させるために、具体的な事例として、Google検索のような情報取得にはGETメソッドが適しており、通販サイトでの個人情報登録やログイン処理など、データをURLに露出させるべきでない場合にはPOSTメソッドが必須であることを解説する。また、GETメソッドの場合はURLにデータが含まれるため「ブックマーク」が可能である一方、POSTメソッドではデータがリクエストボディに含まれるためブックマークしてもデータが保存されないという、ユーザー体験に直結する挙動の違いについても触れる。授業では、HTMLのformタグにおけるmethod属性の指定が、これらの通信方式を決定していることにも言及し、Web開発における実装と理論の結びつきを意識させる。この細目で理解すべき範囲は、HTTP通信の基本的なフロー、GETメソッドとPOSTメソッドの機能的・用途的な違いまで。
|
③ 本主題では、大規模なWebアプリケーションを構築する際に採用される標準的なシステムアーキテクチャである「3層構造」について、各サーバーの役割と分割の意義を中心に解説する。実際の商用システムなどでは、単一のサーバーですべてを処理するのではなく、役割に応じて「Webサーバー」「APサーバー」「DB（データベース）サーバー」の3つに機能を分割して構成することが一般的であることを導入とする。それぞれのサーバーが担う具体的な責務として、WebサーバーはWebブラウザを通じてユーザーと直接的なやり取りを行う窓口としての役割、APサーバーは計算やデータ加工などのビジネスロジックを処理する役割、そしてDBサーバーはデータの保存・更新・削除・参照といったデータ管理を行う役割を持つことを定義し、テキストの表や図を用いて整理する。さらに、なぜこのようにシステムを分割する必要があるのかという「分割の目的」について、システムアーキテクチャの観点から深掘りして説明する。主な理由として、システムのスケーラビリティ（拡張性）と耐障害性の向上が挙げられることを解説する。例えば、アクセス負荷が高まった際に特定の層のサーバーのみを増強できる柔軟性や、一部のサーバーに障害が発生してもシステム全体への影響を最小限に抑えられるリスク分散のメリットを提示する。また、この「分割」という概念が、サーバー構成だけでなくプログラム設計（クラス設計）においても重要であることに言及する。プログラム内でクラスを分割することが、コードの再利用性、可読性、保守性を向上させるのと同様に、インフラ構成においても役割分担がシステムの品質維持に寄与するというアナロジーを用いることで、学生の理解を促進する。授業の最後には、これら3つのサーバーがHTTP通信などを介して連携し、一つのWebアプリケーションとして機能する全体像を再確認し、今後の講義で学ぶSpring Frameworkが主にAPサーバー上のビジネスロジック実装に関わる技術であることを位置付ける。これにより、学生は自身が開発するコードがシステム全体の中でどこに位置し、どのような役割を果たすのかを俯瞰的な視点で捉えることができるようになる。この細目で理解すべき範囲は、Webサーバー・APサーバー・DBサーバーの役割定義、および3層構造を採用する目的とメリットまで。
|
|
キーワード
|
① Webアプリケーション ② クライアントとサーバー ③ APサーバー ④ HTTP通信 ⑤ 3層構造
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で学習したWebアプリケーションの仕組みについて、身近なWebサイトを利用する際に意識的に確認してみること。ブラウザのアドレスバーに表示されるURLの変化や、検索フォーム利用時とログイン処理時での挙動の違いなどを観察し、学習したHTTPメソッド（GET/POST）の特性と照らし合わせて整理すること。また、クライアントとサーバーの役割分担について、自身の言葉で説明できるように概念を再確認すること。
◆次回授業の予習
次回の授業では、システムアーキテクチャの変遷についてより深く学ぶことになるため、今回学習したWebアプリケーションの基本構造が、過去の技術ではどのように実現されていたのか、あるいはどのような課題があったのかを想像しておくこと。特に、動的なWebページを生成するための仕組みについて、一般的な概念としてどのようなアプローチが考えられるか、これまでのプログラミング経験を基に思考を巡らせておくこと。
|
|
2
|
システムアーキテクチャ史２
|
科目の中での位置付け
|
本講義は、Webアプリケーション開発における基礎理論の定着を図る重要な回である。次回以降の実践的な開発演習（Servlet/JSPおよびSpring Framework）に入る前に、Webアプリケーションが動作する仕組み、特にHTTP通信やサーバーの役割分担といったアーキテクチャの根幹を理解することは不可欠である。本回での理論的理解が、後のフレームワーク導入の動機付けや、各レイヤ（層）の役割理解へと直結し、技術の変遷を文脈として捉える基盤となる。
|
|
|
コマ主題細目
|
① Webアプリケーションの基本構造とHTTP通信の仕組み ② APサーバーの役割とシステムアーキテクチャの3層構造 ③ 開発の効率化とフレームワーク導入の意義
|
|
細目レベル
|
① Webアプリケーションが成立するための基本的な構成要素である「クライアント」と「サーバー」の関係性、およびその間で行われる通信プロトコルについて詳説する。まず、クライアントとはサービスを受ける側のコンピュータやソフトウェアを指し、サーバーとはサービスを提供する側のコンピュータやソフトウェアを指すという基本定義を確認する。Webブラウザを通じてインターネットを介し、サーバー上のアプリケーションを利用する形態がWebアプリケーションであることを理解させる。その上で、Webにおける通信の基盤となるHTTP（HyperText Transfer Protocol）の仕組みについて解説する。HTTP通信は、クライアントからの「リクエスト（要求）」と、それに対するサーバーからの「レスポンス（返答）」という一往復のやり取りで構成されている点を強調する。具体的には、ユーザーがブラウザにURLを入力することでリクエストが送信され、サーバーがそのリクエストを受け取り、処理結果をレスポンスとして返し、最終的にブラウザがそれを受け取って画面に表示するという一連のフローを詳細に説明する。また、このリクエストには主に「GETメソッド」と「POSTメソッド」という二つの種類が存在することを解説する。GETメソッドは主に指定したURLの内容を取得するために用いられ、URLの末尾に「クエリストリング」と呼ばれる形式でデータを付加して送信する特徴を持つことを説明する。一方、POSTメソッドは入力情報を送信するために用いられ、データはURLではなく「リクエストボディ」に格納されるため、個人情報などの秘匿性が高いデータの送信や大量のデータの送信に適している点を対比させる。これらの通信方式の違いを理解することは、Webアプリケーションのセキュリティやデータ処理の仕組みを理解する上で極めて重要である。さらに、GETメソッドとPOSTメソッドの使い分けが、ブラウザのブックマーク機能への登録可否など、ユーザー体験にも影響を与える具体例についても触れ、プロトコルレベルの理解を深めさせる。この細目で理解すべき範囲は、クライアント・サーバーモデルの定義から、HTTP通信におけるリクエスト・レスポンスの流れ、およびGETメソッドとPOSTメソッドの特性と使い分けまで。
|
② Webアプリケーションを支えるサーバーサイドのアーキテクチャとして、現代の標準的な構成である「3層構造」について詳説する。実際の商用システムなどでは、単一のサーバーですべてを処理するのではなく、役割に応じてサーバーを物理的あるいは論理的に分割して構成することが一般的である。具体的には、ユーザー（Webブラウザ）と直接やり取りを行い静的なコンテンツなどを配信する「Webサーバー」、ビジネスロジックやデータの加工・計算などの動的な処理を担当する「AP（アプリケーション）サーバー」、そしてデータの保存・更新・参照などのデータ管理を一手に担う「DB（データベース）サーバー」の3つに役割を分割することを解説する。特に本講義の演習で主に使用することになるAPサーバーについては、Webアプリケーションそのものを配置・実行する環境であり、常時稼働してクライアントからのリクエストを待ち受けるという特性を持つことを強調する。このようなサーバー構成の分割を行う目的として、システムのスケーラビリティ（拡張性）と耐障害性の向上が挙げられることを論理的に説明する。例えば、アクセス負荷が高まった際に特定の層のサーバーのみを増強することで対応可能になる点や、一部のサーバーに障害が発生してもシステム全体への影響を最小限に抑えることができる点など、運用面でのメリットを具体的に解説する。また、この「分割する」という考え方は、ハードウェア構成だけでなく、ソフトウェア内部の設計においても重要であることを示唆する。プログラム内においてもクラスや機能を役割ごとに分割することで、コードの再利用性、可読性、保守性が向上することを説明し、後の講義で学ぶレイヤ化アーキテクチャやMVCモデルへの導入とする。サーバーの役割分担を正しく理解することは、Webアプリケーションがどのようにリクエストを処理し、データを永続化しているかという全体像を把握するために不可欠な知識である。この細目で理解すべき範囲は、Webサーバー、APサーバー、DBサーバーのそれぞれの役割定義と、3層構造を採用することによるシステム構築上のメリット（拡張性、耐障害性、保守性）まで。
|
③ システムアーキテクチャの進化の過程で、開発手法がいかにして現在の「フレームワーク」を用いた形式へと変遷してきたか、その背景と意義について解説する。まず、フレームワークとは、ソフトウェアやアプリケーション開発を容易にするための「骨組み」であることを定義する。従来の開発手法、例えばJavaにおけるServletやJSPのみを用いた手動での開発では、リクエストの処理、画面の生成、データベースへの接続といったあらゆる機能を開発者自身が一から実装する必要があった。これに対し、フレームワークはアプリケーション開発において共通して必要となる最低限の機能や構造をあらかじめ提供してくれるものであることを説明する。フレームワークを導入する最大のメリットは、開発にかかる時間とコストの大幅な削減である。データベース接続やセキュリティ対策、通信制御といった汎用的な機能が既に用意されているため、開発者はビジネスロジックの実装など、アプリケーション固有の価値創造に注力することが可能となる。一方で、フレームワークを利用するためには、そのフレームワーク特有のルールや作法を学習し、理解しなければならないというデメリットも存在することを公平な視点で解説する。また、本講義で扱う「Spring」と「Spring Framework」の関係性についても整理する。Spring Frameworkは依存性の注入（DI）やアスペクト指向プログラミング（AOP）といったコア機能を提供するフレームワークであり、Springはそれを含む「Spring Boot」「Spring Security」「Spring MVC」などの多様な機能を提供するフレームワークの集合体であることを体系的に説明する。これらの知識を通じて、なぜ現代のWeb開発においてフレームワークが必須とされるのか、その技術的な必然性と歴史的な背景を理解させる。単にツールとしての使い方を覚えるのではなく、フレームワークが解決しようとしている課題（開発の複雑性、保守性の低下など）を認識することが、エンジニアとしての基礎能力を高めることにつながる。この細目で理解すべき範囲は、フレームワークの定義とメリット・デメリット、およびSpring Frameworkを含むSpringエコシステムの全体像まで。
|
|
キーワード
|
① HTTP通信 ② GETメソッド ③ POSTメソッド ④ APサーバー ⑤ 3層構造
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で学習したWebアプリケーションの仕組みについて、自身の言葉で整理してノートにまとめること。特に、普段利用しているWebサイトを閲覧する際に、裏側でどのようなHTTPリクエストとレスポンスが行われているか、GETとPOSTがどのように使い分けられているかを想像し、クライアントとサーバー間のデータの流れを図解できるようにしておくこと。また、3層構造における各サーバーの役割の違いを明確に説明できるように復習すること。
◆次回授業の予習
次回の授業では、実際に開発環境を構築し、Javaを用いたWebアプリケーション開発の実習を開始する。そのため、開発環境構築の手順（IDEのインストールやDBのセットアップなど）に一通り目を通し、全体の流れを把握しておくこと。また、Javaの基本文法に不安がある場合は、クラスやメソッドの定義方法について確認しておくと、スムーズに実習に入ることができる。
|
|
3
|
HTTPの仕組みと開発環境構築
|
科目の中での位置付け
|
本講義は、全45回のうち第3回目に位置し、第1部「Web開発の歴史と課題」における最初の実践的演習である。これまでの講義で学んだWebの歴史的背景と理論を踏まえ、本回では実際に統合開発環境（IDE）を構築し、Webアプリケーションの動作原理であるHTTP通信を体験する。Java Servletを用いた原始的な実装を通じて、Webサーバーとブラウザ間のリクエスト・レスポンスの仕組みを理解すると同時に、フレームワークを使用しない開発の煩雑さを肌で感じることで、後の回で学ぶSpring Frameworkの有用性を理解するための重要な土台を形成する。
|
|
|
コマ主題細目
|
① Webアプリケーションの構造とHTTP通信の基礎 ② 統合開発環境（IDE）の導入とワークスペースの設定 ③ Java Servletによる初歩的な動的コンテンツ生成の実習
|
|
細目レベル
|
① Webアプリケーション開発を開始するにあたり、まずはその基盤となる仕組みについて、詳細に解説を行う。具体的には、クライアントとサーバーの関係性、APサーバーの役割、そしてHTTP通信のプロトコルについて理解を深める。まず、クライアントとサーバーの概念について定義する。クライアントとはサービスを受ける側（主にWebブラウザ）であり、サーバーとはサービスを提供する側であることを明確にする。Webアプリケーションとは、インターネットを介して利用するアプリケーションであり、その背後ではAPサーバー（アプリケーションサーバー）が常時稼働し、クライアントからの要求（リクエスト）を待ち受けている構造を解説する。
次に、WebブラウザとAPサーバー間で行われるHTTP通信の仕組みについて詳説する。HTTP（HyperText Transfer Protocol）はインターネット上で情報を送受信するためのルールであり、クライアントからの「HTTPリクエスト」と、それに対するサーバーからの「HTTPレスポンス」という一往復のやり取りが基本単位となることを図解を用いて説明する。このリクエストとレスポンスの流れを理解することは、後のトラブルシューティングにおいても極めて重要である。
さらに、HTTPリクエストにおける主要なメソッドであるGETメソッドとPOSTメソッドの違いについて、その特性と使い分けを解説する。GETメソッドは主に指定したURLの内容を取得するために使用され、送信する値はURLの末尾にクエリストリングとして付加される特徴を持つ。一方、POSTメソッドは入力情報を送信するために使用され、データはリクエストボディに格納されるためURLには表示されないというセキュリティ上の利点や、大量のデータ送信に適している点を説明する。「ブラウザのお気に入りに登録できるか否か」という具体例を挙げ、GETは登録可能だがPOSTは不可である理由を、通信の仕組みから論理的に理解させる。
最後に、実際のシステム構成として一般的な「3層構造」について概観する。Webサーバー、APサーバー、DBサーバーがそれぞれどのような役割を担い、負荷分散や保守性の観点からどのように連携しているかを解説し、本講義で構築する開発環境がこの構造のどの部分を担うのかを明確にする。
この細目で理解すべき範囲は、Webアプリケーションにおけるクライアント・サーバー間の通信フロー、GET/POSTメソッドの特性と使い分け、およびWebシステムの基本的な3層構造の役割分担まで。
|
② Javaを用いたWebアプリケーション開発を効率的に行うために不可欠な統合開発環境（IDE）の構築手順とその重要性について手順に従って解説し、実際に学生自身のPCで環境構築を行う。本講義では、Eclipseをベースに必要なプラグインやJDK（Java Development Kit）があらかじめパッケージングされた「Pleiades All in One」を採用する。これにより、個別にJDKや日本語化プラグインをインストールする手間を省き、統一された環境でスムーズに学習を開始できる利点を説明する。
具体的な導入手順として、まず公式サイトからのダウンロードとインストール（解凍）作業を行う。Windows環境におけるパス長の制限や、解凍先ディレクトリに空白や日本語が含まれる場合のトラブルリスクについて注意を促し、適切な配置場所（例：Cドライブ直下など）に環境を構築させる。解凍後は「eclipse.exe」を実行し、初回起動時に求められる「ワークスペース」の設定を行う。ワークスペースとは、作成したソースコードや設定ファイル、成果物などを保存する作業場所であり、このディレクトリ管理がプロジェクト運営の基本となることを理解させる。
Eclipseが起動した後、画面構成や基本的な操作方法について概観する。パースペクティブの概念や、パッケージエクスプローラー、コンソールビューなどの主要な画面要素の役割を説明し、開発作業の流れをイメージさせる。また、外観の変更（テーマ設定）などのカスタマイズについても触れ、学生が長時間作業してもストレスの少ない環境を整える方法を紹介する。
さらに、Webアプリケーションを実行するために必要なAPサーバーとしてのTomcatの存在を確認する。Pleiades All in OneにはTomcatが内包されており、Eclipse上からサーバーの起動・停止を制御できることを説明する。これは、作成したWebアプリケーションをローカル環境で動作確認するために必須の機能であり、サーバービューを通じてそのステータスを管理する方法を習得させる。最後に、環境構築が正しく行われたことを確認するために、簡単な操作を行い、次項目の実習に向けた準備を完了させる。
この細目で理解すべき範囲は、統合開発環境（IDE）の役割とPleiades All in Oneの導入手順、ワークスペースの概念、およびEclipse上でのAPサーバー（Tomcat）の管理方法まで。
|
③ 構築した開発環境を用いて、シラバスの規定に基づき「動的Webプロジェクト」を作成し、Java Servletを用いた最初のWebアプリケーション実装を行う。この実習の主目的は、Javaのコードのみを使用してHTMLを出力する手法を体験し、その過程で生じる実装上の煩雑さを認識することにある。
まず、Eclipseの機能を用いて「動的Webプロジェクト」を新規作成する手順を解説する。プロジェクトのディレクトリ構造を確認し、ソースコードを格納する場所や、Web公開用のディレクトリの役割を理解させる。次に、JavaのクラスとしてServletを作成する。ここでは、「継承」と「オーバーライド」の知識を活用し、HttpServletクラスを継承したクラスを作成させ、doGetメソッドをオーバーライドする。このdoGetメソッドが、先述のGETリクエスト受信時に実行されるメソッドであることを、HTTP通信の理論と紐づけて解説する。
続いて、アノテーションを用いたURLマッピングを行う。クラス宣言部に`@WebServlet`アノテーションを付与し、特定のURLパス（例："/hello"）とこのServletクラスを紐付ける。これにより、ブラウザからそのURLにアクセスがあった際に、TomcatがこのクラスのdoGetメソッドを呼び出す仕組み（コンテナの役割）を説明する。
実装の核心部分として、doGetメソッド内でレスポンスの生成を行う。`HttpServletResponse`オブジェクトを使用して、コンテンツタイプ（text/html）や文字コードを設定し、`PrintWriter`を取得してHTMLタグを文字列として一行ずつ出力するコードを記述させる。例えば、`out.println("＜html＞＜body＞＜h1＞Hello Servlet＜/h1＞＜/body＞＜/html＞");`のように、Javaのプログラムコードの中にHTMLタグが文字列として埋め込まれる形式となる。学生にはこの記述方法を実践させ、HTMLの構造が複雑になった場合に、コードの可読性や保守性が著しく低下することを体感させる。
最後に、サーバー（Tomcat）を起動し、Webブラウザから指定したURLにアクセスして、記述したHTMLが正しく表示されることを確認する。この一連の流れを通じて、動的なWebページ生成の基本原理を習得すると同時に、従来の開発手法における課題（JavaコードとHTMLの混在）を発見させる。
この細目で理解すべき範囲は、動的Webプロジェクトの作成、ServletによるGETリクエストの処理とURLマッピング、およびJavaコードによるHTML出力の実装手順とそれに伴う可読性の課題まで。
|
|
キーワード
|
① HTTP通信 ② APサーバー ③ GETメソッド ④ POSTメソッド ⑤ Tomcat
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で構築したEclipseの開発環境を再度操作し、ワークスペースの場所やプロジェクトの構成を確認すること。また、授業内で解説したHTTP通信の流れ（リクエストとレスポンス）や、GETメソッドとPOSTメソッドの違いについて、講義ノートや配付資料を見返して整理すること。特に、WebブラウザとWebサーバーがどのように情報をやり取りしているか、その基本的な仕組みを自分の言葉で説明できるようにしておくことが望ましい。
◆次回授業の予習
次回の授業では、今回作成したServletをさらに発展させ、フォーム処理の実装を行う。そのため、HTMLのフォームタグ（form、input、submitなど）の基本的な書き方や属性について、既存の知識を再確認しておくこと。また、今回学んだGETメソッドとPOSTメソッドが、実際のフォーム送信においてどのように使い分けられるか、Webサービスの利用シーンを想像しながら思考を巡らせておくこと。特別な資料を読み込む必要はないが、Webの基本動作への関心を高めておくこと。
|
|
4
|
HelloServlet実習とフォーム処理基礎
|
科目の中での位置付け
|
本講義は、Webアプリケーション開発の歴史的変遷を辿る第1部の第4回に位置し、Java Servletを用いた基本的なHTTP通信の実装を行う重要な回である。前回構築した開発環境上で、実際にクライアントからのリクエストを受け取り、レスポンスを返すというWebの基本動作をプログラムとして実装する。これにより、フレームワークを使用しない「素の」開発手法におけるフォーム処理の仕組みと、それに伴う実装上の煩雑さを体験的に理解し、後のSpring Framework導入の必然性を学ぶための土台を形成する。
|
|
|
コマ主題細目
|
① HTTPプロトコルにおけるGETメソッドとPOSTメソッドの理論的差異と挙動 ② Java Servletにおけるリクエスト処理の実装とフォームデータの取得 ③ JavaコードによるHTML出力の実践とその構造的課題の認識
|
|
細目レベル
|
① 本細目では、Webアプリケーションにおけるクライアントとサーバー間の通信基盤であるHTTPプロトコルについて、特にデータの送受信方法であるGETメソッドとPOSTメソッドの違いに焦点を当てて詳細に解説を行う。Webアプリケーションはクライアント（ブラウザ）からのリクエストに対してサーバーがレスポンスを返すことで成立している。このリクエストの送信方法として最も基本的なものがGETとPOSTであり、それぞれの特性と適切な用途を理解することは、堅牢なアプリケーション設計の第一歩である。まず、GETメソッドについて詳説する。GETは「取得」を意味し、主にサーバーから情報を引き出す際に使用される。その最大の特徴は、送信するデータがURLの末尾に「クエリストリング（クエリ文字列）」として付加される点にある。形式は「名前=値」であり、複数の値を送る場合は「&」で連結される。この仕組みにより、検索結果ページなどの特定の状態を持つURLをブックマーク（お気に入り登録）したり、リンクとして共有したりすることが可能となる。しかし、URLにデータが露出するため、パスワードなどの機密情報の送信には不向きであり、またURLの長さ制限により大量のデータ送信には適していないことを理解させる。次に、POSTメソッドについて解説する。POSTは「郵便」や「送信」を意味し、主にサーバーへ情報を登録・更新する際に使用される。POSTメソッドでは、データはURLではなく「リクエストボディ」と呼ばれる通信内部の格納場所に配置されて送信される。これにより、ブラウザのアドレスバーにデータが表示されることはなく、GETメソッドに比べて秘匿性が高まる。また、データ量の制限も基本的には存在しないため、長文のテキストやファイルアップロードなどの大量データの送信に適している。一方で、URLにデータが含まれないため、その状態をブックマークすることはできないという特性も併せて理解させる。授業では、これらの理論的な違いを説明した後、実際のブラウザの挙動や開発者ツール等を通じて、クエリストリングやリクエストボディがどのように構成されているかを確認し、両者の使い分けがセキュリティやユーザビリティに与える影響について考察を深める。この細目で理解すべき範囲は、HTTP通信におけるGETとPOSTの役割、データ送信の仕組み（クエリストリングとリクエストボディ）、およびそれぞれのメリット・デメリットまで。
|
② 本細目では、前項で学んだHTTPメソッドの理論を、Java Servlet技術を用いて具体的なプログラムコードとして実装する方法を学習する。Webブラウザ上に表示されたHTMLフォームからデータが送信された際、サーバー側のJavaプログラムがどのようにそのデータを受け取り、処理を行うのか、その一連のフローを実践形式で習得する。まず、クライアント側の実装としてHTMLのformタグにおけるmethod属性の指定が、通信方式（GETまたはPOST）を決定することを再確認する。その上で、サーバー側のServletクラスにおいて、それぞれの通信方式に対応したメソッド（doGetおよびdoPost）をオーバーライドして実装する必要があることを解説する。Servletコンテナ（Tomcat等）は、受信したHTTPリクエストの種類を判別し、自動的に適切なメソッドを呼び出す仕組みを持っている。学生には、このコンテナによるライフサイクル管理の基本概念を理解させた上で、実際のコーディングを行う。具体的には、HttpServletRequestインターフェースが提供する機能を用いて、クライアントから送信されたパラメータを取得する方法を学ぶ。Spring Frameworkにおけるアノテーションベースのパラメータ取得の背後にある基本的な仕組みを知るため、Servlet APIのgetParameterメソッドを使用した「手動での」データ取得を実践する。ここでは、フォームの入力項目名（name属性）をキーとして値を取得するプロセスを確認する。さらに、日本語などのマルチバイト文字を扱う際に発生しがちな「文字化け」の問題についても触れ、適切な文字コードの設定（setCharacterEncodingメソッド等）がHTTP通信において不可欠であることを説明する。GETメソッドとPOSTメソッドそれぞれでリクエストを送信するフォームを作成し、それを受け取るServletを作成することで、同一のURLに対してもHTTPメソッドが異なれば異なる処理を実行できることや、パラメータの受け渡し方が内部的に共通のインターフェースで抽象化されていることを体験させる。これらの演習を通じて、Webアプリケーションがユーザー入力をどのように処理システムに取り込んでいるか、その根本的なメカニズムの理解を定着させる。この細目で理解すべき範囲は、HTMLフォームとServletメソッドの対応関係、HttpServletRequestを用いたパラメータ取得方法、および文字コード処理の基本まで。
|
③ 本細目では、サーバー側で処理した結果をクライアントに返すためのレスポンス生成処理、特にJavaコード内からHTMLを出力する方法について学習し、その手法が抱える構造的な課題について深く考察する。Servletを用いて動的なWebページを生成する場合、HttpServletResponseインターフェースを使用して、クライアントに対する出力ストリームを取得し、そこにHTMLタグを含む文字列を書き出す必要がある。授業では、まず「HelloServlet」の実習として、response.getWriter().println()メソッドを用い、"..."といったHTMLコードを一行ずつJavaプログラムの中に記述していく作業を実践する。この作業を通じて、学生は直感的に「開発効率の悪さ」と「可読性の低さ」を痛感することになる。Javaというプログラミング言語の中に、デザイン言語であるHTMLが文字列として混在する状態は、コードの見通しを著しく悪化させる。インデントの管理は困難になり、タグの閉じ忘れやクォーテーションの記述ミスなどが頻発しやすく、デバッグも容易ではない。さらに、重要な概念として、「3層構造」や「依存性」の観点からこの実装方法を分析する。本来、ビジネスロジック（処理）とプレゼンテーション（表示）は分離されるべきであるが、Servlet内でHTMLを出力する手法ではこれらが密接に結合（密結合）してしまっている。これにより、例えば画面のデザイン（背景色やフォントなど）を少し変更したいだけであっても、Javaのソースコードを修正し、再コンパイルし、サーバーを再起動するという重い手順が必要となる。この「変更容易性の欠如」は、大規模なWebアプリケーション開発において致命的なボトルネックとなる。本細目の目的は、単にHTMLを出力できるようになることではなく、この「不便さ」や「保守性の低さ」を実体験として強く認識することにある。この強烈な原体験こそが、次回の授業で扱うJSP（JavaServer Pages）による画面と処理の分離、そして後の章で学ぶテンプレートエンジン（Thymeleaf）やSpring MVCといった現代的なフレームワークがなぜ必要とされ、どのようにこれらの課題を解決したのかを理解するための重要な鍵となる。この細目で理解すべき範囲は、ServletによるHTML出力の実装方法、ロジックとデザイン混在による弊害、および保守性と生産性の観点からの課題認識まで。
|
|
キーワード
|
① HTTP通信 ② GETメソッド ③ POSTメソッド ④ クエリストリング ⑤ リクエストボディ
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で学んだHTTPメソッド（GETとPOST）の違いについて、それぞれのデータ送信の仕組みと適した用途を整理すること。また、Servletを用いてフォームデータを受け取る際の一連の流れ（ブラウザからの送信、コンテナによるメソッド呼び出し、パラメータの取得）を頭の中でシミュレーションし、コード記述時の注意点（特に文字コードの扱いなど）を振り返ること。Javaコード内にHTMLを記述することのデメリットを、保守性の観点から自身の言葉で説明できるようにしておくこと。
◆次回授業の予習
次回の授業では、今回課題として挙げられた「JavaコードとHTMLの混在」を解決するための技術であるJSP（JavaServer Pages）について学ぶ。JSPがどのようにして画面（HTML）と処理（Java）を分離しようとしているのか、その基本的な考え方について一般的なWeb技術の文脈で確認しておくこと。また、Webアプリケーションにおける「スコープ」という概念（データの有効範囲）が登場するため、変数の有効範囲などプログラミングの基礎的な概念を再確認しておくと理解がスムーズになる。
|
|
5
|
課題発見型演習①（ログイン機能実装の準備）
|
科目の中での位置付け
|
本講義は、全45回のカリキュラムにおける第1部の第5回に位置し、Webアプリケーション開発の歴史的変遷を体感する重要なフェーズである。前回までのServlet単体による開発で生じた「HTML埋め込みの煩雑さ」という課題に対し、JSP（JavaServer Pages）を導入することで「画面と処理の分離」という解決策を提示する。これは、後のSpring MVCにおけるViewとControllerの役割分担を理解するための原体験となり、フレームワークの必要性を痛感させるための布石となる実践的な演習回である。
|
|
|
コマ主題細目
|
① JSP（JavaServer Pages）の導入と画面・処理の分離 ② RequestDispatcherを用いたフォワード制御の実装 ③ HttpServletRequestによるリクエストスコープでのデータ共有
|
|
細目レベル
|
① 本細目では、Webアプリケーションにおけるプレゼンテーション層（View）の役割を担う技術として、JSP（JavaServer Pages）の概念と基本的な実装方法について詳説し、実践的な演習を行う。前回までの講義において、Servletクラス内部のJavaコード内で`PrintWriter`を用いてHTMLタグを文字列として出力することの非効率性、可読性の低さ、および保守性の欠如を学生は体験している。これに対し、JSPを用いることで、HTMLをベースとしながら必要に応じてJavaコードを埋め込むという、よりWebデザインに親和性の高い開発手法が可能になることを理解させる。具体的には、Eclipse上で新規にJSPファイルを作成し、ログイン画面となるHTMLフォームを記述する演習を行う。この際、JSPファイルの先頭に記述するpageディレクティブの役割、文字エンコーディングの設定、およびHTML5の標準的な構文との整合性について解説する。また、JSPがWebコンテナ（Tomcat）によって初回アクセス時に自動的にServletのソースコードに変換され、コンパイルされて実行されるという内部アーキテクチャについても言及し、JSPも本質的にはServletであることを学術的な観点から理解させる。さらに、画面（JSP）と処理（Servlet）を物理的なファイルとして分離することの意義について、MVCモデルの萌芽としての観点から論じる。開発現場において、デザイナーとプログラマの分業を促進し、各々の責務を明確化することが、システム開発の効率化にいかに寄与するかを認識させる。演習では、ユーザーIDとパスワードを入力する単純なログインフォームを作成し、その送信先（action属性）として、後述する処理担当のServletを指定するまでの一連の流れを実装する。この過程を通じて、静的なHTMLファイルと動的なJSPファイルの違い、およびWebアプリケーションディレクトリ構成内でのJSPの配置場所（WebContentまたはsrc/main/webapp直下など）についての理解も深める。この細目で理解すべき範囲は、JSPの基本構造を理解し、ログイン入力画面を作成してServletへリクエストを送信する準備が整う段階まで。
|
② 本細目では、Webアプリケーションにおける画面遷移の重要な手法の一つである「フォワード（Forward）」について、その仕組みと実装方法を詳説する。HTTPリクエストを受け取ったServletが、必要なビジネスロジックを実行した後、その処理結果の表示を別のリソース（今回はJSP）に委譲するプロセスを扱う。具体的には、`javax.servlet.RequestDispatcher`インターフェースの役割と、`forward`メソッドの挙動について学習する。前回の授業で扱った単純なレスポンス出力とは異なり、フォワードではクライアント（ブラウザ）側からはURLが変化せず、サーバー内部で処理が引き継がれるという特性を持つことを強調する。これにより、ユーザーは内部的な処理の分散（ServletからJSPへの移動）を意識することなく、シームレスな体験を得ることが可能となる。演習においては、先ほど作成したログイン画面（JSP）から送信されたリクエストを受け取るServletクラス（LoginServlet）を作成する。このServlet内で、受け取ったパラメータの検証（簡易的なID・パスワードチェック）を行った後、その結果に応じて適切なJSPへ表示を切り替えるロジックを実装する。ここでは、`request.getRequestDispatcher("遷移先パス").forward(request, response);`という定型的なコード記述を通じて、ServletからJSPへ制御権を移譲する具体的な手順を習得させる。また、フォワードと対比される概念である「リダイレクト（Redirect）」についても触れ、リダイレクトがクライアントに新たなリクエストを再発行させる仕組みであるのに対し、フォワードは同一リクエスト内で処理が完結するため、リクエスト情報の維持が可能である点（次項のスコープに関連）を理論的に区別して理解させる。この制御の分離こそが、後のSpring FrameworkにおけるControllerがView名を返却して画面遷移を行う仕組みの原型であることを示唆し、アーキテクチャの進化の文脈の中で技術を捉えさせる。この細目で理解すべき範囲は、Servlet内でRequestDispatcherを取得し、適切なJSPへ処理をフォワードさせる実装ができる段階まで。
|
③ 本細目では、サーバー内部で連携する複数のコンポーネント間（ServletとJSP）でデータを共有するための仕組みである「リクエストスコープ」について詳説し、その実装能力を涵養する。HTTPプロトコルは本来ステートレス（状態を持たない）な通信であるが、Webアプリケーションにおいては、処理結果を次の画面に引き継ぐ必要性が頻繁に生じる。この課題を解決するために、Webコンテナが提供する`HttpServletRequest`オブジェクトが、単なる通信情報の保持だけでなく、データの格納領域（属性：Attribute）としての役割も果たすことを理解させる。具体的には、Servlet内で`request.setAttribute("キー", オブジェクト)`メソッドを用いてデータを格納し、フォワード先のJSPで`request.getAttribute("キー")`を用いてデータを取り出す一連の流れを演習する。今回のログイン機能演習においては、入力されたユーザー名や、ログイン成功・失敗のメッセージなどをリクエストスコープに格納し、遷移先のJSPでそれを表示する実装を行う。この際、Javaのオブジェクト（Stringや自作クラス）がObject型として格納されるため、取り出し時にキャスト（型変換）が必要になる場合がある点や、JSP側でJavaコード（スクリプトレット）を用いてデータを取り出す際の記述の煩雑さについても体験させる。これは、後に学ぶThymeleafなどのテンプレートエンジンがいかに簡潔にデータバインディングを行えるかを評価するための比較基準となる。また、リクエストスコープの生存期間が「1回のリクエストからレスポンスが返るまで」であることを強調し、ブラウザの更新ボタンを押した場合や、別のページへ遷移した場合にデータが消失する挙動を確認させることで、スコープの概念を正しく認識させる。これにより、データの生存期間に応じた適切なスコープ（リクエスト、セッション、アプリケーション）の使い分けの必要性への気づきを促す。この細目で理解すべき範囲は、Servletで生成したデータをリクエストスコープに格納し、フォワード先のJSPで抽出して画面に表示する一連のデータ連携処理の実装まで。
|
|
キーワード
|
① JSP（JavaServer Pages） ② RequestDispatcher ③ フォワード（Forward） ④ リクエストスコープ ⑤ HttpServletRequest
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の演習で作成したログイン機能のコードを見直し、ServletからJSPへのデータの流れを図解してみることを推奨する。特に、ブラウザのアドレスバーに表示されているURLと、実際に表示されているJSPファイル名が一致しない（ServletのURLが表示されている）現象について、フォワードの仕組みと照らし合わせて考察すること。また、JSPファイル内にJavaコードを記述する「スクリプトレット」の構文について、変数の宣言やif文の使用方法を確認し、HTMLタグとの混在がいかに可読性に影響するかを振り返ること。
◆次回授業の予習
次回は、ログイン状態を維持するための「セッション管理」について学習する。HTTPプロトコルがステートレスであるという特性を再確認し、Webサイトがどのようにして「誰がアクセスしているか」を記憶し続けているのか、その仕組みについて一般的な概念（Cookieなど）を調べておくこと。また、今回学んだ「リクエストスコープ」と対比するために、データの保存期間がより長いスコープが必要となる場面（例：ショッピングカートの中身の保持など）について想像を巡らせておくこと。
|
|
6
|
課題発見型演習②（ログイン機能実装の完成）
|
科目の中での位置付け
|
本講義は、全45回にわたるWebアプリケーション開発演習の第6回であり、第1部「Web開発の歴史と課題（Java Servlet/JSP）」の最終回に位置付けられる。これまでの講義では、HTTPプロトコルの基礎から始まり、ServletとJSPを用いた基本的な動的Webページの生成とデータ受け渡しを学習してきた。今回は、Webアプリケーションにおいて不可欠な「状態管理」と「認証」を実装し、これまでの知識を統合する。同時に、従来の手法（Servlet/JSP）における開発の煩雑さと限界を学生に実体験させ、次部から導入するSpring Frameworkの必要性と利便性を理解するための重要な転換点となる回である。
|
|
|
コマ主題細目
|
① HttpSessionによる状態管理のメカニズム ② 認証機能とアクセス制御の実装手法 ③ 従来の開発手法における課題とフレームワーク導入の動機付け
|
|
細目レベル
|
① Webアプリケーションの基盤となるHTTPプロトコルは、本来「ステートレス（無状態）」なプロトコルであることを改めて体系的に解説する。ステートレスとは、サーバーがクライアントからのリクエストをそれぞれ独立したトランザクションとして扱い、過去のリクエストの状態を記憶しない特性を指す。この特性はサーバーの拡張性を高める一方で、ショッピングカートやログイン状態の維持といった、連続した操作を必要とするアプリケーションの実装において課題となる。この課題を解決するための技術的アプローチとして、Cookieとセッションを用いた状態管理の仕組みについて詳説する。具体的には、サーバーが初回アクセス時に一意な識別子（セッションID）を発行し、クライアント（ブラウザ）がCookieを用いてそのIDを保持・送信することで、サーバー側で同一クライアントからのリクエストを識別するプロセスを図解的に理解させる。
Java Servlet APIにおいて、このセッション管理機能を提供するのが`javax.servlet.http.HttpSession`インターフェースである。授業では、`HttpServletRequest`の`getSession()`メソッドを用いてセッションオブジェクトを取得する方法と、その内部挙動（セッションの新規作成と既存セッションの取得の違い）について解説する。また、`setAttribute(String name, Object value)`メソッドによるデータの保存と、`getAttribute(String name)`メソッドによるデータの取得方法を実践する。ここで特に強調すべき点は、セッションスコープとリクエストスコープの生存期間の違いである。リクエストスコープが1回のHTTPリクエスト・レスポンスのサイクルで消滅するのに対し、セッションスコープはブラウザを閉じるかタイムアウトするまで、あるいは明示的に破棄されるまでデータが保持されることを理解させる。さらに、セッションに保存されるデータはすべて`Object`型として扱われるため、取得時に適切な型へのキャスト（型変換）が必須となる点についても触れる。これはJavaの静的型付けのメリットを活かしにくい部分であり、型安全性や実行時エラーのリスクという観点から、従来手法の潜在的な課題として認識させる必要がある。この細目で理解すべき範囲は、HTTPのステートレス性を補完するセッション管理の仕組みと、Java ServletにおけるHttpSessionオブジェクトの操作方法、およびスコープの概念まで。
|
② 前回の演習で作成したログイン画面のフォーム入力を受け、実際にサーバー側で認証処理を行い、その結果に基づいてセッションを操作する一連の実装プロセスを解説する。まず、ログイン処理を担当するServletにおいて、リクエストパラメータとして送信されたIDとパスワードを取得し、あらかじめ定めた条件（あるいはデータベース照合）と一致するかを検証するロジックを構築する。認証に成功した場合、`HttpSession`オブジェクトを取得し、ログイン済みであることを示す情報（例えばユーザーIDやユーザーオブジェクト）を`setAttribute`メソッドで格納する手順を示す。これにより、サーバー上のメモリ空間にユーザーの状態が保持され、「ログイン状態」という概念が確立されることを理解させる。
次に、ログインが必要なページ（会員専用ページなど）へのアクセス制御、いわゆる「認可」の基本的な実装方法について解説する。具体的には、対象となるServletやJSPの冒頭で`HttpSession`からユーザー情報を取得（`getAttribute`）し、その値がnullである場合（＝未ログイン状態）には、ログイン画面へ強制的に遷移させる処理を記述する。また、ログアウト機能の実装として、`session.invalidate()`メソッドを用いてセッション全体を無効化し、サーバー上の情報を破棄する手順を学ぶ。
さらに、画面遷移の手法として「フォワード」と「リダイレクト」の明確な使い分けについても詳説する。ログイン処理のようなデータ更新を伴うPOSTリクエストの直後には、リロードによる二重送信（再投稿）を防ぐために、フォワードではなくリダイレクト（`response.sendRedirect`）を使用する「PRG（Post/Redirect/Get）パターン」が定石であることを指導する。これにより、ブラウザのURLが適切に更新され、ユーザー体験が向上するとともに、アプリケーションの安全性が高まることを理解させる。これらの実装を通じて、Webアプリケーションにおけるセキュリティの基本となる認証とセッション管理の実装パターンを習得させる。この細目で理解すべき範囲は、ログイン・ログアウト処理におけるセッション操作の実装、未ログインユーザーのアクセス制限（ログインチェック）、および適切な画面遷移（リダイレクト）の使い分けまで。
|
③ 第1部の総括として、これまでの全6回で体験したServletとJSPのみを用いた「素のJava」によるWebアプリケーション開発の手法を振り返り、そこに内在する構造的な課題と限界を体系的に整理する。この振り返りは、次部から学習するSpring Frameworkがいかにしてこれらの問題を解決するかを理解するための重要な動機付けとなる。
第一の課題として、コードの散在と保守性の低さを挙げる。今回の演習で実装したログインチェック処理は、本来ならばアプリケーション全体で共通化されるべき「横断的関心事」であるにもかかわらず、現状では各ServletやJSPに個別に記述する必要がある。これはコードの重複（Don't Repeat Yourself原則の違反）を招き、修正時の影響範囲を拡大させる要因となることを指摘する。また、JSPファイル内にJavaのロジック（スクリプトレット）が混在することや、Servlet内にHTML文字列の生成処理が含まれることにより、可読性が著しく低下し、デザインとロジックの分離が不完全である点も問題視する。
第二の課題は、ボイラープレートコード（定型コード）の多さである。リクエストパラメータの取得、型変換、入力チェック、画面遷移の制御、例外処理といった、ビジネスロジックの本質とは関係のない「配管工事」のようなコードを大量に記述しなければならない現状を認識させる。
第三の課題として、オブジェクト管理と依存性の問題について解説する。これまでの演習では、必要なクラスのインスタンスを都度`new`演算子で生成してきたが、これがクラス間の結合度を高め、将来的な変更や単体テストを困難にしていることを説明する。
これらの課題を整理した上で、現代のJava開発における解決策としての「フレームワーク」の役割を提示する。Spring Frameworkが提供するDI（依存性の注入）コンテナによるオブジェクト管理、AOP（アスペクト指向プログラミング）による共通処理の分離、Spring MVCによる強力な画面遷移制御とデータバインディングといった機能が、いかにして開発者の負担を減らし、生産性と品質を向上させるかという展望を語る。この細目で理解すべき範囲は、Servlet/JSP開発における保守性・生産性の課題（コード重複、結合度、定型処理）の理解と、それらを解決する手段としてのフレームワークの必要性の認識まで。
|
|
キーワード
|
① HttpSession ② ステートレス ③ セッションID ④ リダイレクト ⑤ ボイラープレートコード
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の講義で実装したログイン機能のコードを見直し、HTTPリクエストとレスポンスの流れの中で、どのタイミングでセッションが生成され、データが格納・参照されているかをトレースする。特に、ブラウザの開発者ツールなどを利用してCookie（JSESSIONID）の送受信を確認し、ステートレスなHTTP上で状態が維持される仕組みを再確認する。また、フォワードとリダイレクトの挙動の違いについて、ブラウザのURL表示の変化やリロード時の挙動を含めて整理しておくこと。
◆次回授業の予習
次回からはいよいよSpring Frameworkの学習が始まる。これまでのServlet/JSP開発で感じた「面倒な作業」や「記述量の多さ」を解決するためのツールとしてフレームワークが存在することを念頭に置く。一般的な「フレームワーク」という言葉の意味や、ライブラリとの違いについてインターネット等で調べ、大まかな概念を掴んでおくこと。また、Javaにおける「インターフェース」の役割について、実装クラスを切り替える際のメリットという観点から知識を整理しておくと、次回のDI（依存性の注入）の理解がスムーズになる。
|
|
7
|
Spring Frameworkの概要と環境再構築
|
科目の中での位置付け
|
本講義は、全45回の講義における第2部の開始点に位置します。第1部では、Java ServletとJSPを用いた古典的なWeb開発手法を学習し、その煩雑さと限界を体験しました。第7回からは、現代のJava開発におけるデファクトスタンダードであるSpring Frameworkを導入します。本コマでは、フレームワークを利用する意義を理解し、その全体像を把握するとともに、以降の演習を円滑に進めるための開発環境を再構築します。これは、生産性の高い現代的な開発手法へ移行するための重要な転換点となります。
|
|
|
コマ主題細目
|
① フレームワークの役割とSpring Ecosystemの全体像 ② VisualStudioCode等の導入と設定 ③ リレーショナルデータベース（PostgreSQL）の構築
|
|
細目レベル
|
① 本細目では、まずWebアプリケーション開発における「フレームワーク」の定義と導入の意義について解説します。フレームワークとは、アプリケーション開発を容易にするための「骨組み」であり、これを利用することで開発者は必要最低限の機能実装に集中できるというメリットがあります。一方で、フレームワーク特有のルールや作法を習得する必要があるというデメリットも存在することを、第1部で体験したServlet/JSPの手動実装と比較しながら説明します。
次に、Java開発において最も普及しているSpring Frameworkについて、その構造を「Spring」という広義の集合体と、「Spring Framework」という狭義のコア機能に分類して解説します。次に、Springが提供する主要なプロジェクト群について概観します。具体的には、煩雑な設定を自動化し迅速な開発を可能にするSpring Boot、データベースアクセスを抽象化するSpring Data、Webアプリケーション構築を担うSpring MVC、バッチ処理を提供するSpring Batch、そして認証・認可などのセキュリティ機能を提供するSpring Securityについて、それぞれの役割を説明します。
また、Spring Frameworkの中核をなす機能として、DI（依存性の注入）とAOP（アスペクト指向プログラミング）という用語を紹介します。これらがSpringの根幹を支える技術であることを示唆しつつ、詳細なメカニズムについては以降の講義で扱うため、現段階では「疎結合な設計」や「横断的関心事の分離」を実現するための重要な概念であるという認識を持たせます。
さらに、本講義での学習対象が主にSpring Boot、Spring MVC、DI、AOP、Spring Securityであることを明示し、これらを組み合わせることで、堅牢かつ保守性の高いWebアプリケーションが構築可能になることを理解させます。
この細目で理解すべき範囲は、フレームワークの概念からSpringの全体像まで。
|
② 本細目では、Spring Frameworkを用いた開発を効率的に行うための開発環境の構築を行います。Visual Studio Codeを使用することから、これまで使用してきたJava開発における標準的なIDEであるEclipseとの違いを説明し、日本語化や便利なプラグインを採用する理由を説明します。
また、EclipseでもSpring Frameworkは開発できることから、基本的な構築手順として、まず公式サイトからのインストーラーのダウンロード手順や注意点を解説します。
次に、Visual Studio Codeの初回起動時の設定について解説します。ワークスペースとは、開発したソースコードや設定情報が保存されるディレクトリであり、その役割と重要性を説明し、フォルダとの違いを説明します。また、開発者の好みに応じた外観（テーマ）の変更方法についても触れ、長時間の開発作業における視認性の確保についても言及します。
さらに、VisualStudio Codeの拡張機能についても簡単に触れ、これらが今後の開発でどのように役立つかを予見させます。最後に、開発ツールが正常に起動し、Javaの開発が可能な状態になっていることを確認する手順を実施します。このプロセスを通じて、学生は単にツールをインストールするだけでなく、開発環境がどのように構成され、各ツールがどのような役割を果たしているかを理解します。これにより、将来的に環境トラブルが発生した場合でも、自力で原因を切り分けられる基礎能力を養います。
この細目で理解すべき範囲は、開発環境の構築、インストールから起動確認、外観設定まで。
|
③ 本細目では、Webアプリケーションにおけるデータの永続化を担当するデータベース管理システム（DBMS）の導入を行います。本講義では、オープンソースのリレーショナルデータベース（RDBMS）であり、商用利用を含め広く採用されているPostgreSQLを使用します。まず、データベースとはデータを保存・管理するための「場所」であり、Webアプリケーションが動的なコンテンツを提供するために不可欠な構成要素であることを説明します。
構築手順として、公式サイトからのインストーラーのダウンロードおよびインストールプロセスを詳細に解説します。インストール時には、インストール先のディレクトリ設定、データ保存ディレクトリの設定に加え、スーパーユーザー（postgres）のパスワード設定が重要であることを強調します。このパスワードは後の講義でSpring Bootからデータベースに接続する際に必要となるため、確実に管理させるよう指導します。また、ポート番号（デフォルト5432）の設定や、ロケール（Japanese, Japan）の設定についても触れ、これらが通信や文字コードの扱いに影響することを理解させます。
インストール完了後に表示されるStack Builderについては、今回は追加のコンポーネントインストールを行わないため利用しない旨を説明します。これは不要なソフトウェアの導入を避け、環境をシンプルに保つためです。
最後に、PostgreSQLに付属する管理ツール「pgAdmin 4」の起動と操作方法を習得します。pgAdmin 4を用いてデータベースサーバーへの接続確認を行い、インストールが正常に完了したことを検証します。この際、GUIツールを通じてデータベースの状態を可視化することで、学生はデータベースサーバーがバックグラウンドで稼働している実感を持ちやすくなります。この一連の作業を通じて、アプリケーションサーバーとデータベースサーバーが連携するWebシステムの基本的なインフラ構成についての理解を深めます。
この細目で理解すべき範囲は、PostgreSQLのインストールからpgAdminによる動作確認まで。
|
|
キーワード
|
① フレームワーク ② Spring Boot ③ VisualStudioCode ④ PostgreSQL ⑤ 拡張機能
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の講義では、Spring Frameworkの全体像と各プロジェクトの役割について学びました。Spring BootやSpring MVCなどがそれぞれどのような目的で存在しているのか、講義ノートを見返して整理してください。また、自身のPCに構築した開発環境（EclipseおよびPostgreSQL）について、再度起動手順を確認し、スムーズにツールを立ち上げられるように操作に慣れておくことが重要です。特にpgAdmin 4を用いたデータベースへの接続確認は、今後の演習の基礎となるため、確実に実行できるようにしておいてください。
◆次回授業の予習
次回の講義では、Spring Frameworkの核となるDI（依存性の注入）を理解するために不可欠なJavaの基礎知識を復習します。具体的には「インターフェース」と「ポリモーフィズム（多態性）」の概念が中心となります。これらの用語がJavaにおいて何を意味し、コード上でどのように表現されるかについて、過去に学習したJavaの知識を呼び起こしておいてください。また、クラス間の「依存」とはどういう状態を指すのか、一般的なプログラミングの文脈で考えておくと、次回の講義内容がよりスムーズに理解できます。
|
|
8
|
Javaの基礎知識復習（インターフェースと依存性）
|
科目の中での位置付け
|
本講義は、Spring Frameworkの核心概念であるDI（依存性の注入）を理解するための理論的支柱を構築する重要な回です。Java言語の基本文法として学習済みのインターフェースやポリモーフィズムといった概念を、単なる構文ルールとしてではなく、変更に強く保守性の高いアプリケーションを設計するための「手段」として再定義します。これにより、次章以降で学ぶフレームワークが提供する機能の必要性と利点を深く理解するための土台を形成します。
|
|
|
コマ主題細目
|
① インターフェースの定義と役割およびコンパイルエラーの意義 ② クラス間の依存性と実装依存における課題 ③ インターフェース依存とポリモーフィズムによる解決策
|
|
細目レベル
|
① 本細目では、Java言語におけるインターフェースの構文的特徴とその本質的な役割について、オブジェクト指向プログラミングの観点から詳細に解説します。まず、インターフェースとは、クラスに含まれるメソッドの具体的な処理内容は記述せず、定数とメソッドの型のみを定義したものであることを確認します。Javaにおいてインターフェースを宣言する際にはinterfaceキーワードを使用し、メソッドは処理ブロックを持たない抽象メソッドとして定義されます。この際、インターフェース内で宣言されたメソッドには暗黙的にpublic abstract修飾子が付与され、変数にはpublic static final修飾子が付与されるという言語仕様についても触れ、これらが「実装を持たない仕様の定義」であることを強調します。次に、このインターフェースをクラスが実装（implements）する際のルールについて解説します。実装クラスは、インターフェースで定義されたすべての抽象メソッドをオーバーライドし、具体的な処理内容を記述する義務を負います。ここで重要な概念となるのが「コンパイルエラー」です。プログラムが実行される前段階であるコンパイル時に、文法的な誤りや整合性の欠如を検出する仕組みについて説明します。具体的には、インターフェースを実装すると宣言したクラスが、定義されたメソッドをすべて実装していない場合にコンパイルエラーが発生することを示し、これが「契約」としてのインターフェースの機能を担保していることを理解させます。また、エラーメッセージを読み解き、原因を特定して修正するプロセス自体が、堅牢なプログラムを作成するために不可欠なスキルであることを伝えます。このように、インターフェースは単なるメソッドのリストではなく、クラスがどのような機能を提供すべきかを規定する設計図であり、コンパイルエラーはその設計図通りに実装が行われているかを厳格にチェックする機構であることを、コード例の解説を通じて定着させます。この細目で理解すべき範囲は、インターフェースの宣言と実装の方法、および不適切な実装時に発生するコンパイルエラーの原因と対処法まで。
|
② 本細目では、ソフトウェア開発における「依存性」の定義と、それがもたらす構造的な課題について深く掘り下げて解説します。まず、依存とは、ある要素が他の要素に頼っている状態、または他の要素なしでは機能できない状態を指すことを説明します。プログラミングの文脈において、あるクラス（使う側）が別のクラス（使われる側）の機能を利用するために、そのクラスのメソッドを呼び出したり、インスタンスを生成したりする関係性が「依存」にあたります。具体的には、「使う側」のクラス内でnewキーワードを使用して「使われる側」のクラスのインスタンスを生成し、その参照を通じてメソッドを実行する一連の流れを示します。この際、最も重大な問題となるのが「クラス依存（実装依存）」です。クラス依存とは、「使う側」が具体的な「使われる側」の実装クラス名を直接コード内に記述してしまっている状態を指します。この状態で、もし「使われる側」のクラスを別のクラスに変更する必要が生じた場合、どのような影響があるかをシミュレーションします。例えば、仕様変更により計算処理を行うクラスを別のロジックを持つクラスに差し替える場面を想定します。実装依存の状態では、「使う側」のクラス内でnewをしている箇所や、変数の型宣言部分など、複数の箇所を修正しなければなりません。もし、そのクラスがシステム内の何十、何百という箇所で使われていた場合、そのすべてを修正する必要があり、作業量は膨大になります。また、修正箇所が増えることは、新たなバグを埋め込むリスクを高め、テストの工数も増大させます。このように、修正箇所が多い状態を「依存性が高い」または「結合度が強い」と表現し、これがソフトウェアの保守性や拡張性を著しく低下させる要因であることを論理的に説明します。学生には、安易なnewキーワードの使用が将来的な変更を困難にする技術的負債になり得ることを認識させます。この細目で理解すべき範囲は、プログラムにおける依存性の定義と、クラス依存（実装依存）が引き起こす保守性低下の問題点まで。
|
③ 本細目では、前項で明らかになった実装依存の課題を解決するための手法として、「インターフェース依存」と「ポリモーフィズム」の概念とその実践的適用について詳説します。まず、インターフェース依存とは、「使う側」のクラスが具体的な実装クラスではなく、抽象的なインターフェースに依存する設計手法であることを説明します。具体的には、「使う側」のクラスにおいて、変数の型として実装クラス名ではなくインターフェース名を使用することで、コードの記述を抽象化します。これにより、実際に代入されるインスタンスがどの実装クラスのものであっても、インターフェースが定義するメソッドを通じて操作が可能になります。この変更により、将来的に「使われる側」の実装クラスが変更されたとしても、「使う側」のクラスにおける修正箇所は、newキーワードでインスタンスを生成する一箇所のみに限定されることを示します。これは依存性が低減された状態であり、保守性が向上したことを意味します。次に、この仕組みを支える核心概念である「ポリモーフィズム（多態性）」について復習します。インターフェースの操作に対して、実装クラスが具体的な動作が実行される構造を説明します。同じメソッド呼び出しに対して、背後にあるオブジェクトの実装に応じた異なる振る舞いが行われる性質がポリモーフィズムです。この性質を利用することで、プログラムの柔軟性が飛躍的に高まることを理解させます。最後に、インターフェース依存に切り替えたとしても、依然としてコード内にnewキーワードによるインスタンス生成の記述（依存）が残っている事実に触れ、これを完全に排除して外部から注入する仕組みこそが、次章で学ぶDI（依存性の注入）であることを示唆し、学習の接続を図ります。この細目で理解すべき範囲は、インターフェース型を変数に利用するメリットと、ポリモーフィズムによる疎結合の実現メカニズムまで。
|
|
キーワード
|
① インターフェース ② 実装クラス ③ 依存性 ④ ポリモーフィズム ⑤ 疎結合
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で扱った「インターフェース」と「実装クラス」の関係性について、自身の言葉で整理してノートにまとめてください。特に、なぜ具体的なクラス名で変数を宣言するのではなく、インターフェース型を使用することが推奨されるのか、その理由を「変更時の影響範囲」という観点から論理的に記述してみましょう。また、日常生活の中で「操作手順は同じだが、対象によって結果が異なる」というポリモーフィズムに似た事例を探し、概念の定着を図ってください。
◆次回授業の予習
次回からは、Webアプリケーション開発の基礎知識と支援ツールの学習に入ります。私たちが普段利用しているWebサイトがどのような仕組みで表示されているのか、一般的な「クライアント」と「サーバー」の役割分担について想像を巡らせておいてください。また、インターネットで情報を閲覧する際の通信のやり取り（リクエストとレスポンス）がどのような流れで行われているか、基本的なイメージを持っておくことで、次回の講義内容がよりスムーズに理解できるようになります。
|
|
9
|
Webアプリ必須知識と開発支援ツール
|
科目の中での位置付け
|
本講義は、これまでのServlet/JSPによるプリミティブなWeb開発の学習から、Spring Frameworkを用いた現代的な開発へと移行する直前の重要な転換点に位置します。第2部の最後として、Webアプリケーションの基本構造やHTTP通信の仕組みといった理論的基盤を再確認するとともに、LombokやGradleといった開発効率を飛躍的に高めるモダンなツール群を導入します。これにより、次部から始まるSpring Frameworkの本格的な学習において、本質的なロジックの実装に集中できる環境と基礎知識を確立します。
|
|
|
コマ主題細目
|
① Webアプリケーションの構造とHTTP通信の基礎 ② 開発支援ライブラリLombokの導入と実践 ③ ビルドツールGradleの役割と依存関係管理
|
|
細目レベル
|
① Webアプリケーション開発において、基盤となるネットワークアーキテクチャと通信プロトコルの理解は不可欠です。本細目では、まずクライアントとサーバーの基本的な役割分担について解説します。クライアントはサービスを受ける側としてブラウザなどを通じてリクエストを送信し、サーバーはサービスを提供する側としてそのリクエストを処理してレスポンスを返します。この一連の流れがWebアプリケーションの動作原理であることを再確認します。次に、サーバーサイドの構成として「3層構造」について詳説します。Webサーバーがユーザーとの直接的なやり取りを担当し、AP（アプリケーション）サーバーがビジネスロジックやデータ加工などの動的な処理を行い、DB（データベース）サーバーがデータの保存や参照を担うという役割分担を理解させます。このように機能を物理的または論理的に分割することで、システムのスケーラビリティ（拡張性）や耐障害性が向上し、保守運用が容易になるというメリットをシステムアーキテクチャの観点から解説します。
続いて、Webにおける通信の規約であるHTTP（HyperText Transfer Protocol）について掘り下げます。クライアントからAPサーバーへの「HTTPリクエスト」と、それに対する「HTTPレスポンス」という通信の往復によって情報の送受信が行われる仕組みを整理します。特に、リクエストメソッドであるGETメソッドとPOSTメソッドの違いについて重点的に解説します。GETメソッドはURLの末尾にクエリストリングとしてデータを付加して送信するため、データの取得（参照）に適しており、ブックマークが可能であるという特性を持ちます。一方、POSTメソッドはリクエストボディという見えない場所にデータを格納して送信するため、大量のデータ送信や個人情報などの機密性の高いデータの送信、あるいはデータの登録や更新処理に適していることを説明します。これらの知識は、後のSpring MVCにおけるコントローラの設計やフォーム処理の実装において前提となる重要な概念です。講義では、これらの理論を図解を用いて視覚的に理解させるとともに、実際のWebブラウザでの挙動などを例に挙げながら、抽象的な概念を具体的なイメージとして定着させることを目指します。
この細目で理解すべき範囲は、Webアプリの3層構造の役割分担から、HTTP通信におけるGETとPOSTの特性の違いまで。
|
② Javaによるアプリケーション開発、特にデータ保持用のクラス（EntityやDTOなど）の作成においては、フィールドに対するゲッター（getter）やセッター（setter）、コンストラクタ、`toString`メソッドなどの定型的なコード（ボイラープレートコード）を記述する必要があります。これらのコードはIDEの自動生成機能を用いれば容易に作成可能ですが、クラスのフィールドが増減するたびに再生成が必要となり、ソースコードの可読性を低下させる要因ともなります。本細目では、これらの課題を解決するためのライブラリである「Lombok」について解説し、その導入と実践を行います。Lombokは、アノテーションと呼ばれる注釈をコードに記述することで、コンパイル時に必要なメソッドを自動的に生成してくれるツールです。これにより、開発者は本質的なフィールド定義のみに集中でき、コードの記述量を大幅に削減できることを理解させます。
具体的には、Lombokが提供する主要なアノテーションの機能と使い方を詳説します。フィールドに対して個別にアクセサメソッドを生成する`@Getter`および`@Setter`、クラス内の全フィールドを引数に持つコンストラクタを生成する`@AllArgsConstructor`、引数なしのデフォルトコンストラクタを生成する`@NoArgsConstructor`について、それぞれの役割と生成されるコードのイメージを解説します。さらに、ゲッター、セッターに加え、`equals`、`hashCode`、`toString`といったObjectクラスのメソッドオーバーライドをまとめて自動生成する強力なアノテーションである`@Data`についても触れます。授業では、Spring Initializrを用いてLombokを含めたプロジェクトを作成し、実際にクラスにアノテーションを付加する演習を行います。そして、EclipseなどのIDE上で「アウトライン」ビューなどを通じて、ソースコード上には記述されていないメソッドが裏側で自動生成されていることを確認させます。また、アノテーションが単なるコメントではなく、外部ソフトウェア（この場合はコンパイラやIDE）に対して特定の動作を指示するメタデータとしての役割を果たしていることについても触れ、Javaプログラミングにおけるアノテーションの重要性を認識させます。
この細目で理解すべき範囲は、Lombokの概要と主要なアノテーション（@Data等）の使用方法およびその効果まで。
|
③ 現代のJava開発において、ソースコードのコンパイルからテスト、パッケージング（jarやwarファイルの作成）に至る一連の作業を手動で行うことは稀であり、ビルドツールによる自動化が一般的です。本細目では、本講義で採用するビルドツールである「Gradle」について、その概念と基本的な役割を解説します。Gradleは、JavaやGroovy、Kotlinなどのプロジェクトをビルドするためのツールであり、柔軟なスクリプト記述と高いパフォーマンスを特徴としています。学生には、Gradleが単にコンパイルを行うだけでなく、プロジェクトが必要とする外部ライブラリ（依存ライブラリ）の管理を自動化してくれる点こそが、フレームワークを利用した開発において極めて重要であることを理解させます。
具体的には、Gradleの中核となる設定ファイルである`build.gradle`について解説します。このファイルにプロジェクトの設定や依存関係を記述することで、Gradleが必要なライブラリをインターネット上のリポジトリから自動的にダウンロードし、プロジェクトのクラスパスに追加してくれる仕組み（依存関係の管理）を学びます。これは、従来のように手動でjarファイルをダウンロードして配置する手間を省き、ライブラリのバージョン管理を容易にするものです。授業では、Spring Initializrで生成されたプロジェクトにおける`build.gradle`の内容を確認し、`dependencies`ブロックに記述された依存関係（例えば`spring-boot-starter-web`や前項で扱った`lombok`など）がどのようにプロジェクトに組み込まれているかを確認します。また、Gradleの特徴として、変更された部分だけを再ビルドする「インクリメンタルビルド」による高速化や、プラグインアーキテクチャによる機能拡張性についても触れます。本講義ではGradleの詳細なスクリプト記述方法までは深入りしませんが、提供された設定ファイルを読み解き、必要なライブラリを追加するための基本的な操作スキルを習得させます。これにより、次回以降のSpring Frameworkを用いた本格的な開発において、環境構築やライブラリ管理のトラブルに惑わされず、スムーズに開発を進めるための土台を築きます。
この細目で理解すべき範囲は、Gradleの基本的な役割（ビルドと依存関係管理）およびbuild.gradleファイルによるライブラリ管理の仕組みまで。
|
|
キーワード
|
① 3層構造 ② HTTP通信 ③ Lombok ④ アノテーション ⑤ Gradle
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
Webアプリケーションにおけるクライアントとサーバーの役割、およびAPサーバーを含む3層構造のメリットについて自身の言葉で説明できるように整理してください。また、HTTP通信におけるGETメソッドとPOSTメソッドの用途の違いについて、具体的な利用シーンを想定して復習してください。さらに、今回導入したLombokのアノテーションがどのようなコードを自動生成しているか、およびGradleが開発プロセスにおいて何を自動化しているかについて、要点を確認してください。
◆次回授業の予習
次回の授業では、Spring Frameworkの中核概念である「DI（依存性の注入）」について学びます。オブジェクト指向プログラミングにおけるクラス間の「依存」とはどのような状態を指すのか、また、インターフェースを利用することでその依存関係をどのように疎結合にできるのかについて、これまでのJava学習や第8回の内容を振り返って整理しておいてください。特に「newキーワード」を用いたインスタンス生成がもたらす結合度の高さについて考えておくと、DIの必要性が理解しやすくなります。
|
|
10
|
DI（依存性の注入）の概念とコンテナ
|
科目の中での位置付け
|
講義は、Spring Frameworkの核となる設計思想「DI（Dependency Injection）」の導入回である。第1部で学んだServletによる密結合な開発の課題を解決するため、オブジェクトの生成と管理をフレームワーク側に委ねる「制御の反転（IoC）」を理解する。本回では、理論のみならず、ブラウザへの文字列出力を伴う最小構成のControllerを作成し、Spring Boot上でプログラムが動作する仕組みを体感することで、次回以降の本格的な部品化（Serviceの導入）への基礎を築く。
|
|
|
コマ主題細目
|
① 密結合なプログラムの課題とDIの必要性 ② Spring BootにおけるControllerの作成とブラウザ出力 ③ Beanの概念とDIコンテナによるインスタンス管理の基礎
|
|
細目レベル
|
① これまでのプログラミング、特に第1部で学習したJava Servletを用いた開発においては、あるクラスが別のクラスの機能を必要とする際、利用側のクラス内で直接new演算子を用いてインスタンスを生成することが一般的であった。この状態は「密結合」と呼ばれ、特定のクラスが特定の相手に強く依存していることを意味する。本細目では、密結合な設計が大規模開発や単体テスト、将来的な仕様変更においていかに脆弱であるかを、具体的なコード例を交えて詳説する。例えば、データベース接続を担当するクラスを直接インスタンス化している場合、接続先をモックや別のデータベースに変更するたびに、利用側のコードすべてを修正し、再コンパイル・再デプロイする必要が生じる。この保守性の低下は、商用Webアプリケーション開発において致命的なボトルネックとなる。そこで登場するのが「依存性の注入（DI）」という概念である。DIは、オブジェクトが依存する相手を自ら生成するのではなく、外部（フレームワーク）から「注入」される設計パターンである。これにより、クラス間の結合度は「疎結合」となり、実装の差し替えが容易になる。本節では、まず従来のnewによるインスタンス生成の限界を概観し、なぜ現代のWeb開発においてSpring FrameworkのようなDIコンテナが必要不可欠となったのか、その歴史的背景とアーキテクチャ上の利点を論理的に解説する。学生は、コードの書き方が変わる背後にある「保守性と拡張性の向上」というソフトウェア工学的な意図を理解することが求められる。具体的には、クラス図を用いて依存の方向がどのように変化するかを可視化し、インターフェースを利用した抽象化がDIの恩恵を最大化させる鍵であることを確認する。この細目で理解すべき範囲は、直接的なインスタンス生成がもたらす密結合の弊害と、DIが解決を目指す設計上の目的まで。
|
② DIの概念を具体化するため、本細目ではSpring Bootを用いた「窓口」となるControllerクラスの作成を実践する。第3部全体を通じた「退屈しない学習」を実現するため、抽象的な理論解説に留まらず、実際にブラウザに結果を出力する動的な演習を行う。具体的には、@Controllerアノテーションを付与したJavaクラスを作成し、HTTPリクエストを受け付けるハンドラメソッドを実装する。ここで重要となるのが、ブラウザからのURLアクセス（GETリクエスト）とJavaメソッドを紐付ける@GetMappingアノテーションの役割である。本演習では、Thymeleaf等のテンプレートエンジンを導入する前の段階として、@ResponseBodyアノテーションを使用し、メソッドの戻り値である文字列をそのままHTTPレスポンスのボディとしてブラウザに表示させる手法を詳説する。これにより、学生は複雑な設定ファイルを記述することなく、Javaのコード一つでWeb上の表示が制御できることを実感する。演習課題としては、「/lesson10」というパスに対して、HTMLタグを含むメッセージ（例：＜h1＞DI学習開始＜/h1＞）を返すコントローラーを実装し、内蔵のApache Tomcatサーバーを起動して、ブラウザから「localhost:8080/lesson10」にアクセスする一連のプロセスを完遂する。この過程で、Spring Bootがアノテーションをスキャンし、自動的にルーティングテーブルを構築する「Auto-configuration（自動設定）」の利便性についても触れる。プログラムが動く喜びを早期に体験させることで、目に見えにくい裏側の仕組みであるDIへの学習意欲を維持させる。また、現在のコードがまだController内部に文字列を直接保持している「暫定的な密結合状態」であることを指摘し、次回のServiceクラス導入への動機付けを行う。この細目で理解すべき範囲は、@Controllerと@GetMappingを用いた基本的なWebレスポンスの生成手順とブラウザへの出力確認まで。
|
③ Spring Frameworkにおいて、フレームワークによって生成・管理されるオブジェクトは「Bean（ビーン）」と呼ばれる。本細目では、Springが提供する「DIコンテナ（ApplicationContext）」という管理領域が、どのようにBeanを登録し、必要に応じて注入するのか、そのライフサイクルと管理メカニズムを概観する。学生が混乱しやすいのは、自分でnewを書かないのに、なぜプログラム実行時にオブジェクトが存在するのかという点である。この疑問を解消するため、コンポーネントスキャンという仕組みを解説する。特定のパッケージ配下にあるクラスに@Componentや@Controllerなどのステレオタイプアノテーションが付与されている場合、Spring Bootの起動時にDIコンテナがそれらを自動的に検知し、インスタンス化してメモリ上に保持する。この一連の動作を「制御の反転（IoC: Inversion of Control）」として定義し、プログラマがプログラムの実行フローをすべて記述するのではなく、フレームワークが主導権を握るというパラダイムシフトを詳説する。本節では、実際のデバッグログやIDEのツールを用いて、DIコンテナ内にどのようなBeanが存在しているかを確認する手法を紹介する。また、DIコンテナがシングルトン（原則として1つのインスタンスのみ生成）でオブジェクトを管理することの効率性についても言及し、メモリリソースの最適化という観点からもDIの合理性を説明する。具体的な演習として、簡単なメッセージ保持クラスをBeanとして登録する準備を行い、コンテナが正しくそのクラスを認識している状態をシミュレーションする。これにより、学生は単なるアノテーションの暗記ではなく、Springの裏側で動く「オブジェクトのプール」という実体をイメージできるようになる。この細目で理解すべき範囲は、Beanの定義、コンポーネントスキャンの動作原理、およびDIコンテナが果たす役割の概念的理解まで。
|
|
キーワード
|
① DI（依存性の注入） ② DIコンテナ ③ Bean ④ @Controller ⑤ 制御の反転（IoC）
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
まず自らの手で「Hello Spring Boot」を表示するコントローラーを再構築してください。特に、@Controller、@GetMapping、@ResponseBodyの3つのアノテーションがそれぞれどのような役割（Webの窓口であることの宣言、URLの紐付け、文字列の直接出力）を果たしているかを自分の言葉で説明できるようにします。また、講義で触れた「密結合」と「疎結合」の違いについて、なぜnew演算子を多用することが将来の修正を困難にするのか、具体的な変更シナリオを想定して考察し、DIが必要とされる論理的根拠を整理しておくことが重要です。
◆次回授業の予習
今回作成したコントローラーから「ビジネスロジック（処理）」を切り離し、専門の部品である「Service」クラスを作成します。予習として、Javaの「インターフェース」の役割について復習しておいてください。なぜクラスを直接利用するのではなく、インターフェースを介して利用することが推奨されるのか、多態性（ポリモーフィズム）の観点から見直しておくことが、次回のDI実践編を深く理解する助けとなります。また、Springにおける@Serviceアノテーションの役割についてテキストの該当箇所を一読し、部品をSpringに「登録」するイメージを膨らませておいてください。
|
|
11
|
DIの基礎：部品（Service）の作成
|
科目の中での位置付け
|
本回は、第10回で作成したControllerから「ビジネスロジック（処理）」を分離し、Spring Frameworkが管理するコンポーネントとして「Service」クラスを構築する工程を学習する。これは、多層アーキテクチャ（レイヤ化）の第一歩であり、DI（依存性の注入）の真価を発揮させるための重要なステップである。単一のクラスに全ての機能を詰め込むのではなく、役割ごとに部品化する設計思想を、具体的なコード実装を通じて習得する。
|
|
|
コマ主題細目
|
① Serviceクラスの定義と役割の分離 ② ステレオタイプアノテーションによるBean登録の実践 ③ 疎結合な設計に向けたインターフェースの活用理論
|
|
細目レベル
|
① Webアプリケーションの開発において、リクエストの受付とレスポンスの返却を担当する「Controller」に、計算やデータ加工といった「ビジネスロジック」を直接記述することは、コードの再利用性や保守性を著しく低下させる要因となる。本細目では、Controllerからロジックを切り離し、専門の「Service」クラスへと役割を委譲するプロセスを詳説する。具体的には、第10回でController内に記述したメッセージ生成処理を、新しく作成する`FortuneService`などのクラスへ移動させる。この分離により、例えば「同じ計算処理を別の画面でも使いたい」あるいは「バッチ処理からも呼び出したい」といった要望に対し、コードを重複させることなく対応できるメリットを概観する。授業では、まずControllerが肥大化することの弊害（ファットコントローラー問題）を提示し、それに対してServiceが「純粋なJavaオブジェクト（POJO）」としてどのように振る舞うべきかを学術的な視点から解説する。学生は、単にコードを別のファイルに分けるという作業レベルの理解を超えて、ソフトウェア工学における「単一責任の原則（Single Responsibility Principle）」に基づいた設計の重要性を理解する必要がある。簡単なロジックをService側に実装させ、Controllerは単にその結果をブラウザに渡すだけの「薄い窓口」へと純化させる演習を行う。この一連の作業を通じて、プログラムの各パーツが独立して存在し、特定の役割に特化することの構造的な美しさと、変更に対する強さを、実際のブラウザ出力の変化（リロードするたびに運勢が変わる動作など）を確認しながら実践的に学習する。この細目で理解すべき範囲は、Controllerからビジネスロジックを抽出してServiceクラスを定義し、役割を完全に分担させる手法まで。
|
② 作成したServiceクラスをSpring Frameworkの管理下に置き、DIの対象とするためには、Springに対してそのクラスが「部品（Bean）」であることを知らせる必要がある。本細目では、`@Service`アノテーションを中心に、ステレオタイプアノテーションの仕組みと動作原理を詳説する。学生は、クラスの宣言部に`@Service`と記述するだけで、Spring Boot起動時に自動的にクラスがスキャンされ、DIコンテナ内にシングルトンインスタンスとして生成される仕組みを実践する。ここで重要なのは、なぜ`@Component`ではなく`@Service`を使うのかという点である。学術的な観点からは、これらは機能的には同等であるが、セマンティック（意味論）な違いがあることを解説する。`@Service`は「ビジネスロジックを提供する層」であることを明示し、将来的にAOPによるトランザクション管理などの対象になりやすいという特性を持つ。授業内では、実際にアノテーションを付与したServiceクラスを作成し、ログ確認機能やデバッガを用いて、アプリケーション起動時にコンテナがどのようにインスタンスを初期化しているかを追跡する。また、複数のControllerから同じServiceを利用する場合でも、コンテナが同一のインスタンスを効率的に管理していることを概観し、メモリ管理の観点からもDIコンテナの優位性を理解させる。演習では、前細目で作成した運勢取得ロジックを持つクラスにアノテーションを付与し、エラーなくアプリケーションが起動することを確認する。このステップを経ることで、学生は「自分でインスタンスを生成（new）する責任」から解放され、フレームワークにインスタンス管理を委ねる「IoC（制御の反転）」の実体的な挙動を、確実な知識として定着させる。この細目で理解すべき範囲は、`@Service`アノテーションによるBeanの自動登録と、DIコンテナによるインスタンス管理のライフサイクルまで。
|
③ DIの真の恩恵である「差し替え可能性」を最大限に引き出すためには、具体的な実装クラスではなく「インターフェース」に対して依存する設計が不可欠である。本細目では、インターフェースを用いた「抽象化」の概念と、それがDIとどのように組み合わさることで疎結合なシステムを実現するかを詳説する。現状、学生は特定のServiceクラスを直接利用しているが、これを「インターフェースを介した呼び出し」に変更する意義を講説する。例えば、`FortuneService`インターフェースを定義し、その実装として「日本語版」と「英語版」のクラスをそれぞれ用意するシナリオを想定する。呼び出し側（Controller）のコードを一切書き換えることなく、Springの設定やアノテーションを調整するだけで、ブラウザに出力される言語を切り替えられることを、実例を挙げて解説する。これは「依存性の逆転原則（Dependency Inversion Principle）」の実践であり、上位モジュールが下位モジュールの具体的な実装に依存してはならないというオブジェクト指向設計の極意を学ぶ機会となる。授業では、インターフェースと実装クラスの関係を図示し、ポリモーフィズムがWebフレームワークの中でどのように具現化されているかを論理的に分析する。演習課題として、既存のServiceをインターフェース化し、それを継承した実装クラス（Impl）を再定義するリファクタリングを行う。これにより、将来的な拡張性（モック化によるテスト容易性や、別実装への切り替え）を担保するための高度なコーディングパターンを習得する。学生は、インターフェースを「契約」として捉え、システム全体の構造を柔軟に保つための論理的思考能力を涵養することが求められる。この細目で理解すべき範囲は、インターフェースを利用したServiceの定義方法と、それによる実装の隠蔽および疎結合化のメリットまで。
|
|
キーワード
|
① @Service ② ビジネスロジック ③ POJO ④ シングルトン ⑤ インターフェース
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
まずControllerとServiceの役割分担を明確に再認識してください。自分で作成したFortuneServiceが、単なるJavaクラスから@Serviceアノテーション一つで「Springが管理する特別な部品（Bean）」へと変化する過程を振り返ります。また、インターフェースを導入する前後のコードを比較し、なぜインターフェースを介することで「呼び出し側（Controller）」が「具体的な作り手（Serviceの実装）」を意識しなくて済むようになるのか、その設計上の利点を自分の言葉で整理してください。ブラウザにリロードのたびに異なる結果が出ることを確認し、ロジックが正常に分離されているか確認することが重要です。
◆次回授業の予習
今回作成した「部品（Service）」を、ついに「窓口（Controller）」へとガッチャンコさせる「インジェクション（注入）」の工程を学びます。予習として、第10回で触れた@Autowiredアノテーションについて、テキストや公式リファレンスで予習しておいてください。特に、コンストラクタによる注入と、フィールドへの直接注入の違いについて軽く目を通しておくと、次回の実習がスムーズになります。また、第11回で学んだインターフェースが、注入の際にどのように型として指定されるのかを想像しながら、これまでのコードを見直しておいてください。
|
|
12
|
DIの実践：コンストラクタインジェクションと不変性
|
科目の中での位置付け
|
本回は、第10回で作成した「Controller（窓口）」と第11回で作成した「Service（部品）」を結合させる、DI（依存性の注入）の核心部である。かつて主流であった@Autowiredによるフィールド注入ではなく、現代のSpring Boot開発におけるベストプラクティスである「コンストラクタインジェクション」を習得する。アノテーションを明示せずともSpringが自動で依存を解決する最新の仕様を学び、堅牢でテストのしやすいソフトウェア設計の基礎を確立する。
|
|
|
コマ主題細目
|
① フィールド注入の課題とコンストラクタ注入の推奨理由 ② アノテーション省略による最新のDI実装手法 ③ finalフィールドと不変性（Immutability）による安全性向上
|
|
細目レベル
|
① Spring Frameworkの進化過程において、長らく@Autowiredをメンバ変数に直接付与する「フィールド注入」が多用されてきた。しかし、現代のWebアプリケーション開発においては、この手法はいくつかの設計上の問題を抱えていると指摘されている。本細目では、フィールド注入が抱える「依存関係の隠蔽」や「単体テストの困難さ」といった課題を学術的な視点から詳説する。例えば、フィールド注入を用いたクラスは、Springコンテナなしでインスタンス化すると依存先がnullとなり、リフレクションを用いなければテストダブルを差し込むことができない。これに対し、コンストラクタインジェクションは、インスタンス生成時に必ず依存オブジェクトを引数として要求するため、依存関係が外部に公開され、コンパイル時に不整合を検知できる利点がある。授業では、従来のフィールド注入のコードと、推奨されるコンストラクタ注入のコードを比較し、ソフトウェア工学における「オブジェクトの完全性」の観点から後者がいかに優れているかを解説する。学生は、単にアノテーションをどこに書くかという問題ではなく、クラスが自身の動作に必要なものを明示的に要求するという、オブジェクト指向の基本原則に立ち返った設計思想を概観する。また、依存先が注入されないままメソッドが呼ばれることによるNullPointerExceptionを未然に防ぐ防御的プログラミングの重要性を、具体的なエラーケースを想定して理解を深める。この細目で理解すべき範囲は、フィールド注入のデメリットと、コンストラクタ注入が推奨される論理的背景まで。
|
② アノテーション省略による最新のDI実装手法: Spring 4.3以降の重要な変更点として、クラス内のコンストラクタが一つのみである場合、@Autowiredアノテーションを省略しても自動的にDIが行われる仕様が導入された。本細目では、この「アノテーションなしのコンストラクタインジェクション」が現代のSpring Boot開発における事実上の標準（デファクトスタンダード）であることを詳説する。学生は、第10回で作成したControllerに、第11回のServiceを引数に持つコンストラクタを手動で実装し、アノテーションを記述しなくてもプログラムが正常に動作することを実践する。これにより、フレームワーク固有のコードを最小限に抑え、プレーンなJavaに近い形でビジネスロジックを記述する手法を習得する。授業では、Springが起動時にどのようにコンストラクタを解析し、DIコンテナ内から適切なBeanを探し出して注入しているのか、その内部メカニズムを論理的に分析する。具体例として、複数の依存先がある場合でも、コンストラクタの引数を増やすだけでSpringが適切に解決する様子を概観する。この手法は、コードの可読性を高めるだけでなく、特定のフレームワークへの依存度を下げる効果があることを強調する。演習では、学生自身の手で既存のControllerを書き換え、アノテーションを削ぎ落としたシンプルなコンストラクタ実装を完遂させる。この過程を通じて、魔法のようなアノテーションに頼るのではなく、Javaの言語仕様としてのコンストラクタがWebフレームワークの中でいかに強力な役割を果たすかを深く理解させる。この細目で理解すべき範囲は、アノテーションを省略したコンストラクタインジェクションの具体的な記述法と、その動作原理まで。
|
③ finalフィールドと不変性（Immutability）による安全性向上: コンストラクタインジェクションを採用する最大の技術的メリットの一つは、依存するオブジェクトを保持するフィールドをfinalとして宣言できる点にある。本細目では、Javaにおけるfinal修飾子の意義を再確認し、Webアプリケーションの各コンポーネントを「不変（Immutable）」に保つことが、並列処理やバグの抑制においていかに重要であるかを詳説する。フィールド注入では初期化後に値を書き換えられるリスクがあったが、finalを付与したコンストラクタ注入では、一度セットされたServiceなどの部品が途中で変更されることを言語仕様として禁止できる。これにより、実行時の安全性が飛躍的に向上することを解説する。授業内では、実際にフィールドにfinalを付与し、コンストラクタで初期化し忘れた場合にコンパイルエラーが発生することを確認する演習を行う。これは「不完全な状態のオブジェクトを生成させない」という堅牢な設計手法の実践である。また、第3部全体のテーマである「ブラウザでの動作確認」として、複数のService（例：占いServiceと挨拶Service）をfinalフィールドとして持ち、それらを組み合わせてブラウザに複合的なメッセージを出力するプログラムを構築する。これにより、複数の部品が安全に統合され、一つの窓口を構成する疎結合なアーキテクチャの完成形を体感させる。学生は、不変性がもたらす「副作用のない設計」の価値を、実際のコードを通じて論理的に考察する能力を涵養する。この一連の学習は、第4部以降のより複雑なドメインモデル設計において、確固たる基礎知識となる。この細目で理解すべき範囲は、finalフィールドを用いたコンストラクタインジェクションの実装と、不変性がもたらす設計上の利点まで。
|
|
キーワード
|
① コンストラクタインジェクション ② finalフィールド ③ 不変性（Immutability） ④ @Autowired省略 ⑤ 疎結合
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習 現代のSpring Boot開発における最も重要な作法である「コンストラクタインジェクション」を確実にマスターしてください。まず、フィールド注入とコンストラクタ注入のコードを書き比べ、なぜfinalキーワードがコンストラクタ注入でしか使えないのか、その理由をJavaの言語仕様と照らし合わせて整理してください。また、@Autowiredを書かなくてもSpringが自動的に依存関係を解決する様子を、実際の動作ログやブラウザ出力から再確認し、アノテーションに頼りすぎないシンプルなコードがもたらす可読性の高さを実感することが重要です。
◆次回授業の予習 次回の第13回からは、DIと並ぶSpringの最重要概念「AOP（アスペクト指向プログラミング）」を学びます。予習として、これまで作成したControllerやServiceの全てのメソッドに「処理開始」と「処理終了」のログを出力する場面を想像してください。もし100個のメソッドがあったら、100箇所に同じコードを書く必要がありますか？AOPは、こうした「どこにでも現れる共通の処理」を一箇所にまとめ、対象のコードを一切汚さずに「外側から差し込む」魔法のような技術です。「横断的な関心事」という言葉の意味を調べておいてください。
|
|
13
|
AOP（アスペクト指向）の概念と共通処理の分離
|
科目の中での位置付け
|
本回は、DIと並ぶSpring Frameworkの二大柱の一つである「AOP（Aspect Oriented Programming）」の導入回である。第12回までに構築したControllerとServiceの構成を維持しつつ、ビジネスロジックの本筋とは無関係な「共通処理（ログ出力や計測など）」を、元のコードを一切汚さずに「外側から」追加する手法を学ぶ。これにより、ソフトウェアの関心事を分離し、保守性を極限まで高める設計思想を習得する。
|
|
|
コマ主題細目
|
① オブジェクト指向の限界と横断的関心事の分離 ② AOPの基本用語（アスペクト、アドバイス、ポイントカット）の体系的理解 ③ 既存コードを修正しない「後付け」処理の論理構造
|
|
細目レベル
|
① オブジェクト指向の限界と横断的関心事の分離: システム開発において、認証、ログ出力、トランザクション管理などの処理は、多くのクラスやメソッドにまたがって共通して必要とされる。本細目では、これらを従来のオブジェクト指向プログラミング（OOP）のみで実装しようとした際に生じる「コードの散在（Scattering）」と「コードの絡まり（Tangling）」という問題を学術的に分析する。例えば、全てのServiceメソッドの開始時と終了時に実行ログを出力する場合、OOPでは全メソッドに同じコードを記述しなければならず、本質的なビジネスロジックの見通しが悪化するだけでなく、仕様変更時に膨大な修正コストが発生する。こうした問題を解決するために提唱されたのが、AOP（アスペクト指向プログラミング）である。本節では、ビジネスロジックを「コア関心事」、ログ出力などの共通機能を「横断的関心事（Cross-cutting Concerns）」として定義し、これらを分離して管理することの設計上の優位性を詳説する。学生は、単なるプログラミング技法としてではなく、大規模システムの複雑性を制御するための高度なモジュール化技術としてAOPを概観する。具体例として、第12回で完成させた占いアプリに対し、後から「どのメソッドがいつ呼ばれたか」という監視機能を追加するシナリオを想定し、既存のJavaコードを1行も書き換えずに実現する道筋を示す。この過程を通じて、開発効率と品質を両立させるための「関心事の分離」の重要性を、論理的思考に基づき深く理解することが求められる。この細目で理解すべき範囲は、横断的関心事の概念と、OOPを補完する技術としてのAOPの必要性まで。
|
② AOPの基本用語（アスペクト、アドバイス、ポイントカット）の体系的理解: AOPの実装には、特有の専門用語の理解が不可欠である。本細目では、Spring AOPにおいて中心的な役割を果たす「アスペクト（Aspect）」「アドバイス（Advice）」「ポイントカット（Pointcut）」「ジョインポイント（Joinpoint）」といった用語の定義と相互関係を詳説する。アスペクトは横断的な機能をまとめた単位であり、アドバイスはその「具体的な処理内容」、ポイントカットは「どこに適用するか」という条件を指す。授業では、これらの概念を「誰が」「いつ」「どこで」という直感的な枠組みに当てはめて解説し、複雑なアーキテクチャを体系的に整理する。特に、ポイントカット指示子（AspectJ式）を用いたメソッドの絞り込み手法については、ワイルドカードを用いた柔軟な指定方法（例：全てのServiceクラスの全てのメソッドを対象にする等）を論理的に分析する。また、アドバイスの実行タイミングとして、処理の前（Before）、後（After）、正常終了時（AfterReturning）、例外発生時（AfterThrowing）、および前後を包み込む（Around）の5種類があることを概観し、それぞれの用途（ログ、計測、エラーハンドリング等）を対比させて解説する。学生は、これらの用語を単なる記号として暗記するのではなく、Springが内部でどのようにメソッドをインターセプト（遮断）して追加処理を挟み込んでいるのかという動的な動作イメージを構築する。この抽象的な概念の理解が、次回の具体的なコード実装における確固たる基盤となる。この細目で理解すべき範囲は、AOPを構成する各要素用語の定義と、それらが連携するアーキテクチャの構造理解まで。
|
③ 既存コードを修正しない「後付け」処理の論理構造: AOPの最大の特長は、ターゲットとなるクラス（Serviceなど）のソースコードを完全に無傷のまま保ちながら、実行時に機能を拡張できる点にある。本細目では、Springが内部で生成する「プロキシ（代理オブジェクト）」という仕組みを詳説する。DIコンテナからBeanを取得する際、Springは実体クラスを直接渡すのではなく、AOPの処理が組み込まれたプロキシを生成して提供する。学生は、第12回で学んだDIと今回のAOPが、このプロキシという技術によって密接に連携していることを論理的に分析する。ブラウザからリクエストが届き、ControllerがServiceを呼び出す際、その呼び出しは一度プロキシによってトラップされ、指定されたアドバイス（ログ出力など）を実行してから本物のServiceメソッドへと転送される。授業内では、このリクエストの流れを図解し、呼び出し側も呼び出される側も互いの追加機能を意識する必要がないという「透明性」のメリットを概観する。演習に向けた準備として、Eclipseのコンソール画面に、特定のURLにアクセスしたタイミングで自動的にログが表示される様子をデモンストレーションし、AOPの「非侵襲性」を視覚的に提示する。これにより、学生は「一度作ったプログラムを汚さずに強化できる」というAOPの魔法のような利便性を実感し、大規模開発におけるチーム分担やメンテナンスの容易さを、学術的・実践的な両面から考察する能力を涵養する。この一連の解説を通じて、Spring Frameworkが提供する高度な抽象化の恩恵を深く理解させる。この細目で理解すべき範囲は、プロキシ経由によるAOPの実行メカニズムと、ターゲットコードを修正しないことの設計的意義まで。
|
|
キーワード
|
① AOP（アスペクト指向） ② 横断的関心事 ③ アドバイス ④ ポイントカット ⑤ プロキシ
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習 AOPがなぜ「横断的」と呼ばれるのか、その概念を自分の言葉で整理してください。特に、ログ出力や計測といった共通処理を、各メソッドに直接書く場合（OOPのみ）と、一箇所にまとめて後付けする場合（AOP利用）で、コードの可読性や修正の手間がどのように変わるかを具体的に考察することが重要です。また、アスペクト、アドバイス、ポイントカットの3つの用語の関係性を図示し、それぞれが「共通処理の定義」「実行タイミング」「適用対象」のどれに対応しているかを確実に復習しておいてください。
◆次回授業の予習 次回は、いよいよAOPを実際にコーディングし、ブラウザでアクセスした瞬間にコンソールへログが出力される演習を行います。予習として、第12回で作成したServiceクラスのパッケージ名とクラス名を正確に確認しておいてください。AOPの設定（ポイントカット）では、「どのパッケージのどのクラス」を対象にするかを文字列で指定するため、この正確な名前が必要になります。また、@Aspectや@Beforeといったアノテーションについてテキストを読み、これまで学んだDIのアノテーションとどのように使い分けるのかイメージを膨らませておいてください。
|
|
14
|
AOPの実装演習
|
科目の中での位置付け
|
本回は、第13回で学んだAOPの理論を具体的なコードとして実装し、Webアプリケーションに適用する実践回である。第12回で構築した「コントローラー―サービス」の構成に対し、一切の修正を加えることなく、外部からログ出力機能を「織り込む（Weaving）」演習を行う。ブラウザからのリクエストに応じてサーバーコンソールに動的にログが表示される様子を確認し、AOPによる非侵襲的な機能拡張の利便性を体感する。
|
|
|
コマ主題細目
|
① @Aspectアノテーションを用いたアスペクトクラスの定義 ② ポイントカット指示子による適用対象の精密な指定 ③ アドバイスの実装とブラウザ連動による動作検証
|
|
細目レベル
|
① @Aspectアノテーションを用いたアスペクトクラスの定義: AOPをSpring Boot上で有効化するためには、共通処理を定義する専用のJavaクラスを作成し、それをDIコンテナに「アスペクト」として認識させる必要がある。本細目では、クラスレベルに付与する@Aspectおよび@Componentアノテーションの役割を詳説する。学生は、まずLoggingAspectといった名称で新しいクラスを作成し、これが通常のビジネスロジックを持つクラスとは異なり、システム全体に横断的な影響を与える特殊な「部品」であることを理解する。学術的な観点からは、Spring AOPがコンポーネントスキャンを通じてアスペクトを検知し、対象となるBeanに対してプロキシ（代理オブジェクト）を生成するプロセスを論理的に分析する。授業内では、アスペクトクラス自体もDIコンテナの管理下（Bean）にある必要があることを強調し、@Componentを忘れるとSpringがそのクラスを無視してしまい、AOPが機能しないという実践的なトラブルシューティングについても概観する。具体的なコード例として、クラス宣言の直前にこれら2つのアノテーションを記述する「おまじない」のような構成から始め、Spring Bootアプリケーションが内部でどのように「アスペクト（共通の関心事）」を登録し、既存のプログラムへの割り込み準備を整えるのかを詳細に解説する。学生は、Eclipse等のIDE上で新しいクラスを作成し、エラーなくプロジェクトが起動することを確認する。この初期設定のプロセスを通じて、フレームワークが暗黙的に行っているオブジェクトのスキャンと登録の仕組みを実体として捉える。この細目で理解すべき範囲は、アスペクトクラスの宣言方法と、Spring BootにおけるAOPの有効化手順まで。
|
② ポイントカット指示子による適用対象の精密な指定: アスペクトが「どこで」実行されるかを決定するのがポイントカットである。本細目では、AspectJの正規表現を用いたポイントカット指示子（execution式）の記述方法を詳説する。学生は、特定のパッケージ、特定のクラス、あるいは特定のメソッド名といった多様な条件で、共通処理の適用範囲を絞り込む手法を習得する。例えば、execution(* com.example.demo.FortuneService.*(..))という式が、「FortuneService内のすべてのメソッド」を指すことを論理的に分析し、ワイルドカード（*や..）の正確な意味を概観する。授業では、むやみに広範囲を対象にするとシステムのパフォーマンスに影響を与える可能性を指摘し、設計意図に沿った「最小特権の原則」に基づくポイントカット定義の重要性を解説する。具体的な演習として、第11回・12回で作成した運勢を占うServiceのメソッドのみを狙い撃ちするポイントカットを記述させ、意図しないメソッド（Controller自体など）には処理が混入しないことを確認させる。これにより、学生は「元のプログラムを一行も汚さない」だけでなく、外部から極めて精密にプログラムの挙動をコントロールできるAOPの柔軟性を深く理解することが求められる。また、ポイントカットを独立したメソッドとして定義し、複数のアドバイスで使い回す手法についても触れ、コードの再利用性を高めるモダンな記述スタイルを提示する。この過程を通じて、学生は「ターゲットを定義する」というAOP特有の設計思考を、実際のパッケージ構造に照らし合わせながら習得する。この細目で理解すべき範囲は、execution式を用いたポイントカットの構文理解と、適切な適用範囲の設計手法まで。
|
③ アドバイスの実装とブラウザ連動による動作検証: AOP実装の最終段階として、実行される具体的な処理内容（アドバイス）を記述し、実際のWeb動作と連動させる。本細目では、@Beforeアノテーションを用いた前処理の実装を詳説する。具体的には、Serviceのメソッドが実行される直前に、コンソールへ「【AOPログ】運勢を計算します...」といったメッセージを出力するコードを記述する。ここで重要なのは、アドバイスメソッドの引数にJoinPointオブジェクトを受け取ることで、実行中のクラス名やメソッド名を動的に取得できる点である。授業では、この情報を活用して、どのURLから来たリクエストがどの部品を動かしているのかを可視化する手法を概観する。実装完了後、学生はブラウザから/fortune等のURLにアクセスし、自身の操作と連動してEclipseのコンソールにリアルタイムでログが刻まれる様子を確認する。これは、目に見えないプロキシの存在を確信する「動きのある学習」のハイライトである。また、アドバイスを無効化（コメントアウト）するだけでログが消え、有効化すれば再びログが出ることを確認させ、AOPがいかに「着脱可能（Pluggable）」な技術であるかを実感させる。学生は、ControllerやServiceのコードには「ログ出力」の一文字も書かれていないにもかかわらず、画面をリロードするたびに背後でログが記録されるという現象から、関心事の分離がもたらす設計上の美しさを体験する。この一連の動作検証を通じて、大規模システムにおいて特定の機能（セキュリティやトランザクション）を全画面に一斉適用する際のAOPの絶大な威力を論理的に考察する能力を涵養する。この細目で理解すべき範囲は、@Beforeアドバイスの実装方法と、JoinPointを用いたコンテキスト情報の取得、および動作確認まで。
|
|
キーワード
|
① @Aspect ② @Before ③ ポイントカット指示子 ④ execution式 ⑤ JoinPoint
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習 第14回の復習では、まず自分が作成したアスペクトクラスが、ターゲットであるServiceクラスのコードを一行も修正せずに機能を付加できていることを、改めてソースコードを見直して確認してください。特に、ポイントカット指示子（execution式）の書き方を復習し、もし「全てのController」にログを出したい場合はどのように書き換えるべきか、自分なりに式を考えてみることが重要です。また、コンソールに表示されたログの内容を確認し、JoinPointからどのような情報が取得できているかを整理しておいてください。
◆次回授業の予習 次回の第15回は、第3部の締めくくりとして、AOPの最も実用的かつ重要な応用例である「トランザクション管理」を学びます。予習として、銀行振込の例を想像してください。「自分の口座から残高を減らす」処理の直後にエラーが起きて、「相手の口座の残高を増やす」処理が失敗したらどうなるでしょうか？このように、複数の処理を「すべて成功か、すべて失敗か」のどちらかに保つ仕組みをトランザクションと呼びます。Springの@Transactionalアノテーションについて、テキストで概要を調べておいてください。
|
|
15
|
トランザクション管理とAOP
|
科目の中での位置付け
|
本講義は、全45回にわたるWebアプリケーション開発演習の第15回であり、第3部「Spring Frameworkのコア機能（DIとAOP）」の最終回に位置付けられる。これまでに学習したDI（依存性の注入）およびAOP（アスペクト指向プログラミング）の理論と基礎的な実装演習を踏まえ、本回ではAOPの実務における最も代表的かつ重要な応用例である「トランザクション管理」を扱う。これにより、フレームワークが提供する機能がいかにして開発効率と保守性を向上させるかを理解し、次部以降のWeb表示層およびデータベース操作の実装へとスムーズに移行するための重要な結節点となる。
|
|
|
コマ主題細目
|
① トランザクションの概念と「不整合」の体験 ② @Transactionalによる自動ロールバックの実装 ③ AOPによるトランザクション制御の内部構造と第3部総括
|
|
細目レベル
|
① トランザクション処理の概念と重要性: 本細目では、Webアプリケーション開発においてデータの整合性を維持するために不可欠な概念である「トランザクション」について、その定義と重要性を学術的な視点から詳細に解説する。まず、トランザクションとは、データベースに対する一連の更新処理を、論理的に分割不可能なひとつの単位としてまとめたものであることを定義する。具体的な事例として、銀行口座間での資金移動（振込処理）を取り上げる。例えば、A口座からB口座へ資金を移動する場合、「A口座の残高を減らす処理」と「B口座の残高を増やす処理」の2つのデータベース更新操作が必要となる。これらの処理は、ビジネスロジック上、双方が完全に実行されるか、あるいは双方が全く実行されないかのいずれかである必要があり、片方のみが実行された状態で処理が終了することは許容されない。もし、A口座の減算処理後にシステム障害が発生し、B口座の加算処理が行われなかった場合、データ不整合が発生し、深刻な信頼性の欠如を招くことになる。このような事態を防ぐために、トランザクション管理機能が存在することを説明する。 本節の実習では、あえて「トランザクションがない状態」での事故を再現する。Serviceクラスに「自分の残高を減らす」「相手の残高を増やす」という2つのメソッド呼び出しを記述し、その間に`throw new RuntimeException("通信エラー発生");`を挿入する。学生はブラウザからこの処理を実行し、コンソール上で「自分の金は減ったが、相手の金が増えていない（＝お金が消えた）」という不整合の状態を数値で確認する。この実体験を通じて、コミットとロールバックの役割、およびデータ整合性維持の重要性を、単なる座学を超えた危機感とともに理解させる。また、Webアプリケーションでは、多数のユーザーが同時にアクセスするため、トランザクション管理が適切に行われていない場合、データの競合や矛盾が生じるリスクが高まる点についても触れる。学生には、トランザクション管理が単なるデータベースの機能ではなく、信頼性の高いアプリケーションを構築するための根幹をなす技術であることを認識させ、次項以降で学ぶSpring Frameworkによる制御の必要性を強く動機付ける。この細目で理解すべき範囲は、トランザクションの定義、コミットとロールバックの役割、およびデータ整合性維持の重要性まで。
|
② AOPを用いないトランザクション実装の課題: 本細目では、Spring FrameworkのAOP機能を利用せずにトランザクション管理を実装しようとした場合に直面する技術的な課題と、コード品質への悪影響について具体的に解説する。前項で学んだトランザクション制御（コミットやロールバック）を、従来のJava標準技術であるJDBCなどを用いて手動で実装する場合の手順をシミュレーションし、その煩雑さを浮き彫りにする。通常、手続き型の手法でトランザクションを管理する場合、ビジネスロジックを記述するメソッドの内部において、まずデータベース接続を取得し、自動コミットモードを無効化する設定記述が必要となる。続いて、try-catch-finally構文を用い、tryブロック内に本来の業務処理（SQL実行など）を記述し、全ての処理が正常に完了した直後にコミットメソッドを呼び出す記述を行う。さらに、例外が発生した場合を想定してcatchブロックを配置し、その中でロールバックメソッドを呼び出す処理を記述しなければならない。最後に、finallyブロックでデータベース接続を確実に切断する処理も必要となる。 このボイラープレートコードの問題を理解させるため、学生には「もし手動でロールバックを書くなら」という擬似コードを提示し、本来2行で済むはずの「振込処理」が、20行以上の複雑なエラー処理コードに埋もれてしまう様子を観察させる。これを学術的には「関心の錯綜」と呼び、ソフトウェアの可読性と保守性を著しく低下させる要因となることを詳説する。数百のメソッドで同様のデータベース操作を行う場合、全ての箇所に同じようなtry-catch構造を記述することは、記述の重複を生むだけでなく、開発者がロールバックの記述を忘れるなどの人為的ミス（バグ）を誘発するリスクを高める。また、将来的にトランザクション管理の仕組みを変更する必要が生じた際、アプリケーション全体に修正が波及するという問題点も指摘する。これらの分析を通じて、ビジネスロジックとトランザクション制御ロジックが密結合している状態の弊害を理解させ、これらを分離する必要性を論理的に導き出す。この細目で理解すべき範囲は、手動によるトランザクション管理のコード構造、ボイラープレートコードの問題点、およびそれが引き起こす可読性と保守性の低下まで。
|
③ Springにおける宣言的トランザクション管理: 本細目では、Spring Frameworkが提供するAOPを活用した「宣言的トランザクション管理」の仕組みと、それによる課題解決のアプローチについて解説する。Spring Frameworkでは、トランザクション管理という横断的関心事を、ビジネスロジックから完全に分離して扱うことが可能であることを示す。具体的には、`@Transactional`というアノテーションを利用する方法を詳説する。開発者は、トランザクション制御を適用したいメソッドに対して、このアノテーションを付与するだけでよい。これにより、ソースコード上からはコミットやロールバックの記述が一切排除され、純粋なビジネスロジックのみが記述されたクリーンな状態が実現される。 実習では、①で作成したエラーの出るServiceメソッドに`@Transactional`を一行書き加える。再度ブラウザからアクセスし、例外が発生したにもかかわらず、自分の残高が減っていない（＝Springが自動で巻き戻した）ことを確認する。この魔法のような挙動の裏側にある技術的背景として、前回学習したAOPの概念を再適用して説明する。`@Transactional`が付与されたクラスがDIコンテナによってインスタンス化される際、Springは動的にそのクラスの「プロキシ（代理）」オブジェクトを生成する。このプロキシは、実際のメソッドを実行する「前」にトランザクションを開始し、実行中に例外がスローされた場合には自動的にロールバックを行う制御フローが組み込まれている。これはAOPにおける「Around Advice」の応用例である。学生には、この仕組みによって、開発者がインフラレベルの複雑な制御から解放され、ビジネスロジックの実装に集中できるメリットを強調する。また、アノテーション一つで制御が可能になることは、コードの記述量を減らすだけでなく、システムの仕様を把握しやすくする効果もあることを説明する。最後に、第3部の総括として、DIとAOPがいかに現代の開発を支えているかを総括し、第4部以降の演習へと繋げる。この細目で理解すべき範囲は、宣言的トランザクション管理の概要、`@Transactional`アノテーションの役割、およびAOPプロキシによる自動制御のメカニズムまで。
|
|
キーワード
|
① トランザクション ② コミット ③ ロールバック ④ @Transactional ⑤ 宣言的トランザクション管理
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の実習では、例外を意図的に発生させて「お金が消える（データ不整合）」現象と、@Transactionalによる「自動的な復旧（ロールバック）」を体験しました。復習課題として、なぜアノテーション一行でデータの安全が守られるのか、その裏側で動いている「AOPプロキシ」の動きを図解してください。特に、メソッドの「前」と「後」でSpringがどのような命令を代行しているかを整理し、手動で書くコードと比べてどれほどミスが減るかを考察してください。
◆次回授業の予習
次回からは第4部に入り、Web表示層の開発技術であるMVCモデルとThymeleafについて学習します。これまでは「文字」をブラウザに返していましたが、次回からは「HTMLファイル」を表示させます。予習として、Javaの「Model（モデル）」「View（ビュー）」「Controller（コントローラ）」がそれぞれどのような役割を担っているのか、一般的なMVCアーキテクチャの概要を調べてください。また、HTMLの基礎的なタグについても再度確認しておくと、画面作成がスムーズになります。
|
|
16
|
MVCモデルとSpring MVCの仕組み
|
科目の中での位置付け
|
本講義は、Spring Frameworkを用いたWebアプリケーション開発演習の第4部に位置し、Web表示層の開発を開始する重要な転換点である。これまでに学習したDIやAOPといったコア機能を基盤とし、今回からはユーザーインターフェースを伴うWebアプリケーションの構築手法を学ぶ。具体的には、Webアプリケーションアーキテクチャの標準であるMVCモデルの概念と、Spring MVCにおける実装および動作原理を理解し、次回以降の画面作成やデータ連携の土台を築くものである。
|
|
|
コマ主題細目
|
① MVCモデルの概念と役割分担 ② Spring MVCの全体像と処理フロー ③ Spring MVCによる基本実装とURL設計
|
|
細目レベル
|
① 本細目では、Webアプリケーション開発における最も基本的なアーキテクチャパターンであるMVCモデルについて、その概念と目的を学術的な視点から詳説する。まず、MVCとは「Model（モデル）」、「View（ビュー）」、「Controller（コントローラ）」の頭文字を取ったものであり、アプリケーションの機能をこれら3つの役割に分割して設計・実装する手法であることを解説する。具体的に、Modelはビジネスロジックやデータの処理・保持を担当し、アプリケーションの核となる計算やデータベース操作を行う部分であると定義する。Viewはユーザーインターフェースを担当し、Modelが保持するデータをユーザーに分かりやすい形式（WebアプリであればHTML）で表示する役割を持つことを説明する。ControllerはModelとViewの橋渡し役であり、ユーザーからの入力を受け取り、Modelに処理を依頼し、その結果を表示すべきViewを選択して制御する役割であることを明確にする。
次に、なぜこのような役割分担が必要なのかについて、第1部で学習したServlet/JSPによる開発における課題と対比させながら論じる。ServletのみでHTMLを出力する場合や、JSP内にJavaコードが混在する場合、画面のデザイン変更がロジックに影響を与えたり、逆にロジックの修正が画面表示を破壊したりするリスクが高かったことを想起させる。MVCモデルを導入することで、機能ごとの独立性が高まり、デザイナーとプログラマの分業が容易になる点や、修正範囲を局所化できるため保守性が向上する点、さらに一つのModelに対して複数のView（PC用、スマホ用など）を用意できる再利用性の高さといったメリットを体系的に理解させる。また、現代のWebフレームワークの多くがこのMVCモデルを採用しており、Spring FrameworkにおいてもSpring MVCというモジュールがこの役割を担っていることを導入として説明する。
最後に、MVCモデルは単なるプログラムの書き方ではなく、システムを整理し、複雑性を管理するための重要な設計思想であることを強調し、各コンポーネントが疎結合であることの重要性を認識させる。この細目で理解すべき範囲は、MVCモデルの各要素（Model, View, Controller）の定義と役割、およびそれらを分離することによる開発上のメリットを理論的に理解するまで。
|
② 本細目では、Spring Frameworkが提供するWebアプリケーションフレームワークである「Spring MVC」のアーキテクチャと、リクエストを受信してからレスポンスを送信するまでの内部処理フローについて解説する。Spring MVCは、前項で学んだMVCモデルをJava Webアプリケーションにおいて実現するための機能群であり、Web層の開発を効率化するための強力な基盤であることを説明する。
授業では、クライアント（Webブラウザ）から送信されたHTTPリクエストが、サーバー内部でどのように処理され、最終的にHTMLとして返却されるかの一連の流れを、順を追って詳細に解説する。まず、クライアントからのリクエストはSpring MVCのフロントコントローラ（DispatcherServlet等の中心的な制御機構）によって受け付けられる。この制御機構は、リクエストされたURLやHTTPメソッド（GET/POST等）の情報に基づき、その処理を担当すべき適切なController（コントローラ）およびそのメソッドを特定して呼び出す。
次に、呼び出されたControllerは、必要なビジネスロジックを実行する。現段階では単純な画面表示のみを扱うが、本格的なアプリケーションではここでService層を呼び出し、データベース操作などの処理を行うことになる点を補足する。Controllerでの処理が完了すると、その結果として「次に表示すべき画面（View）の名前」を返却する。Spring MVCはこのView名を受け取り、対応するテンプレートファイル（HTMLファイル等）を探し出す。
その後、View（テンプレートエンジン）は、Controllerから渡されたデータを用いて動的にHTMLを生成する。この工程をレンダリングと呼ぶ。最終的に生成されたHTMLは、HTTPレスポンスとしてクライアントに返送され、ブラウザ上に画面が表示される。学生には、この一連のフローにおいて、Spring MVCがいかにしてリクエストの振り分けやViewの解決を自動化し、開発者がControllerの実装や画面作成に集中できる環境を提供しているかを理解させる。また、この仕組みにより、リクエスト処理の入口が一元管理され、セキュリティ対策や共通処理の適用が容易になるアーキテクチャ上の利点についても概観する。この細目で理解すべき範囲は、クライアントからのリクエストがControllerに到達し、処理結果に基づいてViewが選択され、レスポンスが返却されるまでのSpring MVCにおける一連の処理フローを理解するまで。
|
③ 本細目では、実際にSpring MVCを用いた簡単なWebアプリケーションを作成し、Controllerの実装方法とURLマッピングの仕組み、およびテンプレートエンジンThymeleafとの連携について実践的に解説する。まず、Spring MVCを利用するためのプロジェクト構成として、ビルドツール（Gradle）の設定ファイルにおいて「Spring Web」および「Thymeleaf」の依存関係が必要であることを確認する。
次に、Controllerクラスの作成方法を詳説する。Javaクラスに対して「@Controller」アノテーションを付与することで、そのクラスがSpring MVCのコントローラとして認識され、DIコンテナによって管理されるBeanとなることを説明する。このアノテーションこそが、単なるJavaクラスをWebリクエストを処理可能なコンポーネントに変える重要な目印であることを強調する。
続いて、リクエストを受け付けるメソッドの実装について解説する。メソッドに対して「@RequestMapping」や「@GetMapping」などのアノテーションを付与し、引数にURLパス（例: "/hello"）を指定することで、特定のURLへのアクセスとJavaメソッドが紐づけられる仕組み（ルーティング）を習得させる。メソッドの戻り値として文字列（String）を返す場合、それが遷移先のView名（テンプレートファイル名）として解釈されるSpring MVCの規約についても詳説する。例えば、"hello"という文字列を返せば、所定のフォルダ（src/main/resources/templates）内にある"hello.html"が呼び出される仕組みである。
また、Viewの作成にはテンプレートエンジン「Thymeleaf」を使用することを導入し、通常のHTMLファイルとして記述しつつ、サーバーサイドで処理される動的な要素を組み込める点に触れる。最後に、Spring BootにおけるURL表記のルールや、Controllerクラス単位でのパス指定（クラスレベルの@RequestMapping）によるURL階層の整理方法など、RESTfulなURL設計の基礎についても概観し、整理されたWebインターフェースを構築するための作法を指導する。これにより、学生はJavaコードとWeb上のURL、そしてHTMLファイルがどのように連携して動作するかをコードレベルで把握する能力を養う。この細目で理解すべき範囲は、@Controllerおよびマッピング用アノテーションを用いたControllerクラスの実装方法と、View名返却による画面遷移の仕組み、および基本的なURL設計手法を習得するまで。
|
|
キーワード
|
① MVCモデル ② Spring MVC ③ Controller ④ View ⑤ Thymeleaf
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で学習したMVCモデルの概念図を、自分なりに白紙に書き出し、Model、View、Controllerそれぞれの役割と言葉の定義を再確認すること。また、Spring MVCにおけるリクエストからレスポンスまでの処理フローを、テキストの説明を参考にしながらノートに整理し、どのタイミングでControllerが呼ばれ、どのようにViewが選択されるかを論理的に説明できるようにしておくこと。さらに、授業で扱ったアノテーションの意味を振り返り、JavaクラスがWebアプリの一部として機能する仕組みを復習すること。
◆次回授業の予習
次回の授業では、テンプレートエンジンThymeleafを用いた動的な画面作成と、ControllerからViewへのデータ受け渡しについて学習する。そのため、テキストの該当箇所を読み、Thymeleafとは何か、その特徴について概要を把握しておくこと。特に、Javaのプログラム側から画面（HTML）へデータを渡すための「Model」インターフェースという仕組みが登場するため、それがどのような役割を持つものなのか、説明を読んでイメージを掴んでおくこと。また、HTMLの基本的なタグについても知識を確認しておくとスムーズである。
|
|
17
|
Thymeleafの基礎とModel
|
科目の中での位置付け
|
本講義は、Webアプリケーション開発においてユーザーインターフェースを担うView層の実装技術を習得するための重要な導入回である。前回学んだSpring MVCの全体像に基づき、実際にControllerからViewへ動的にデータを伝達する具体的な手法を学ぶ。特に、テンプレートエンジンThymeleafの特性と、データ共有の核となるModelインターフェースの理解は、次回以降の動的な画面構築演習における必須の基礎能力となる。
|
|
|
コマ主題細目
|
① テンプレートエンジンThymeleafの概要と特徴 ② Modelインターフェースによるデータ管理 ③ ModelとModelAndViewの実装比較
|
|
細目レベル
|
① 本細目では、Spring Bootを用いたWebアプリケーション開発において標準的に採用されるテンプレートエンジンであるThymeleaf（タイムリーフ）の概要とその技術的特徴について詳細に解説する。まず、Webアプリケーションにおけるテンプレートエンジンの役割について概観する。テンプレートエンジンとは、雛形となるテンプレートファイルと、プログラム処理によって生成された動的なデータを合成し、最終的な成果物（Webアプリの場合は主にHTML）を生成するためのソフトウェアコンポーネントである。これまで学習してきたJSP（JavaServer Pages）もテンプレートエンジンの一種と言えるが、Thymeleafはより現代的なWeb開発の要件に適した特性を有している。
授業では、Thymeleafの最大の特徴である「ナチュラルテンプレート」という概念について深く掘り下げる。従来のJSPや他のテンプレートエンジンでは、独自のタグや構文を使用するため、テンプレートファイルをそのままWebブラウザで開いても正しく表示されない、あるいはレイアウトが崩れるという問題があった。これに対し、Thymeleafは標準的なHTMLタグの「属性」として独自の構文を記述するスタイルを採用している。Webブラウザは未知の属性を無視してレンダリングを行う性質があるため、Thymeleafで記述されたファイルは、サーバーを通さずに直接ブラウザで開いても、静的なHTMLとしてデザインを確認することが可能である。この特性により、Webデザイナーが作成したHTMLファイルを、プログラマが大きく構造を変えることなくテンプレートとして利用できるため、開発プロセスにおける分業と協業が円滑になるという利点を学生に理解させる。
また、Spring FrameworkおよびSpring Bootとの親和性についても解説する。Spring Bootでは、組み込みTomcatを使用して実行可能なJARファイルを生成してデプロイする手法が一般的であるが、JSPはこの形式での動作に制約が多い。一方、ThymeleafはJavaのクラスパス上のリソースとしてテンプレートを扱うことが容易であり、Spring Bootの標準的な構成において推奨される技術スタックとなっている。さらに、ThymeleafがサーバーサイドでHTMLを生成する「サーバーサイドレンダリング（SSR）」の仕組みであることを再確認し、クライアントサイドで動作するJavaScriptフレームワークとの役割の違いについても触れることで、Webアーキテクチャ全体における位置付けを明確にする。
この細目で理解すべき範囲は、Thymeleafの定義、ナチュラルテンプレートの概念、およびSpring Boot開発において採用される理由まで。
|
② 本細目では、Spring MVCアーキテクチャにおいて、ビジネスロジックの処理結果をView（画面）へ伝達するための中心的な機構であるModelインターフェースについて詳説する。MVCモデルにおいて、Controllerはリクエストを受け付け、必要な処理を行った後、その結果を表示用のデータとしてViewに渡す責務を持つ。この「データの受け渡し」を実現するためにSpring Frameworkが提供している抽象化されたコンテナが`org.springframework.ui.Model`インターフェースである。授業では、まずこのModelインターフェースがどのようにしてController内で利用可能になるかを、DI（依存性の注入）の観点から解説する。開発者はControllerのハンドラメソッドの引数として`Model`型の変数を宣言するだけで、SpringのDIコンテナが自動的にModelの実装インスタンスを生成し、メソッド呼び出し時に注入してくれる仕組みを理解させる。
次に、Modelインターフェースが提供する主要なメソッド、特に`addAttribute`メソッドの使用方法と挙動について詳細に解説する。`addAttribute`メソッドは、第一引数に「属性名（キー）」となる文字列を、第二引数に「属性値（データ）」となるオブジェクトを指定する。この構造はJavaの`Map`インターフェースに類似しており、キーと値のペアでデータを管理するものであることを説明する。ここで設定されたデータは、View側（Thymeleafテンプレート）において、指定した属性名を用いて参照することが可能となる。このメカニズムにより、Javaプログラム内のオブジェクト（文字列、数値、JavaBeans、リストなど）が、HTML生成時に動的なコンテンツとして展開される。
さらに、Modelに格納されたデータの生存期間（スコープ）についても言及する。Modelに追加された属性は、基本的にはHTTPリクエストの処理中のみ有効な「リクエストスコープ」として扱われる。これは、第1部で学習した`HttpServletRequest`の`setAttribute`メソッドによるデータ共有と本質的に同等であることを示し、サーブレット技術の抽象化という観点からSpring MVCの利便性を理解させる。また、具体的な例を用い（例えば）「現実世界でのaddAttributeのイメージ」を参考に、荷物（データ）を配送トラック（Model）に積み込み、目的地（View）まで運ぶという比喩を用いて、抽象的な概念を具体的にイメージできるように指導する。
この細目で理解すべき範囲は、Modelインターフェースの役割、DIによる利用方法、addAttributeメソッドによるデータ格納の仕組みまで。
|
③ 本細目では、ControllerからViewへデータと遷移先情報を伝達するための実装パターンとして、前述のModelインターフェースを使用する方法と、`ModelAndView`クラスを使用する方法の二つを取り上げ、それぞれの特徴と実装上の違いについて比較解説する。Spring MVCでは、ハンドラメソッドの戻り値や引数の構成によって、柔軟に実装スタイルを選択できる特徴がある。これまでの細目で扱ったModelインターフェースを使用する場合、メソッドの戻り値は遷移先のView名を示す`String`型となる。この場合、データは引数で受け取ったModelオブジェクトに格納し、遷移先情報は戻り値で返すというように、データとビューの指定が分離された記述となる。
一方、`ModelAndView`クラスを使用する場合、データ（Model）と遷移先ビュー（View）を一つのオブジェクトとしてまとめて管理する。授業では、`ModelAndView`クラスのインスタンス生成、`addObject`メソッドによるデータの追加、および`setViewName`メソッドによるビュー名の設定という一連の手続きをコード例を通じて解説する。このクラスを使用する場合、ハンドラメソッドの戻り値の型は`ModelAndView`となり、メソッド内で生成・設定したインスタンスをリターンすることになる。これにより、データと遷移先がカプセル化され、一つの戻り値として扱われる点がModelインターフェースを利用する場合との構造的な違いである。
授業の後半では、これら二つの手法の「使い分け」について、テキストの内容に基づきつつ、現代的な開発トレンドの観点からも考察を加える。一般的には、Modelインターフェースを使用するスタイルの方が、メソッドのシグネチャ（引数と戻り値の定義）を見るだけで「何を受け取り、何を返すか」が明確であり、テストも容易であるため推奨される傾向にある。しかし、条件分岐によって遷移先と渡すデータが複雑に連動する場合など、データとビューをセットで扱いたい場面では`ModelAndView`が有用なケースもあり得る。学生には、両方の実装方法を読解・記述できる能力を養いつつ、プロジェクトの方針やコードの可読性を考慮して適切な方法を選択する判断力を涵養する。また、内部的にはどちらの方法をとってもSpring MVCの処理フローにおいて適切に変換され、同様の結果が得られることを理解させる。
この細目で理解すべき範囲は、ModelAndViewクラスの使用方法、Model利用時とのコード記述の差異、および両者の使い分けの指針まで。
|
|
キーワード
|
① テンプレートエンジン ② Thymeleaf ③ Modelインターフェース ④ ModelAndViewクラス ⑤ addAttributeメソッド
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の講義で学んだThymeleafの概要と、ControllerからViewへのデータ受け渡しの仕組みについて、講義資料を見直して整理すること。特に、Modelインターフェースを用いたデータの格納方法と、それがView側でどのように利用されるかのイメージを確実に定着させること。また、Modelを使用する場合とModelAndViewを使用する場合のコードの記述の違いについて、それぞれの特徴を自分の言葉で説明できるように要点をまとめておくこと。
◆次回授業の予習
次回の授業では、Thymeleafの具体的な記述方法について実践的な演習を行う。そのため、HTMLの中に変数を埋め込む際の基本的な考え方や、プログラミングにおける変数の出力、サニタイズ処理の必要性について、一般的なWeb開発の知識として確認しておくこと。また、変数を画面に表示する際に、どのようなケースでセキュリティ上のリスク（クロスサイトスクリプティングなど）が発生しうるかについて、基礎的な概念を調べておくこと。
|
|
18
|
Thymeleafの実践①
|
科目の中での位置付け
|
本講義は、全45回にわたるWebアプリケーション開発演習の第18回目であり、第4部「Web表示層の開発」の中核を成す重要な回である。前回までに学習したMVCモデルの概念とModelインターフェースによるデータ受け渡しの基礎を踏まえ、本回ではテンプレートエンジンThymeleafを用いた具体的なViewの実装技術に着手する。動的なWebページ生成において最も基本的かつ頻繁に使用されるデータの表示方法と、画面遷移の基盤となるリンク生成技術を習得することで、以降の回で扱う複雑な制御構文やフォーム処理を理解するための確固たる土台を構築する位置付けにある。
|
|
|
コマ主題細目
|
① 基本的なデータ表示とサニタイズ処理 ② リテラル置換と各種演算子の利用 ③ 標準URL式によるリンク生成とパス解決
|
|
細目レベル
|
① 本細目では、Thymeleafにおける最も基礎的な機能である変数の表示方法と、Webセキュリティにおいて極めて重要なサニタイズ処理について詳説する。まず、Thymeleafが「ナチュラルテンプレート」と呼ばれる所以である、HTMLタグの属性として振る舞う `th:` 属性の仕組みについて解説する。既存のHTMLファイルをブラウザで直接開いた場合でもレイアウトが崩れず、サーバーを経由した場合のみ動的な値に置き換わるという特性は、デザインとロジックの分離を促進し、開発効率を向上させる重要な概念である。具体的には、 `th:text` 属性を用いて、ControllerからModelオブジェクト経由で渡されたデータをHTML要素のボディ部分に展開する方法を実践的に解説する。その際、変数式 `${...}` を用いてJavaのオブジェクトやそのプロパティにアクセスする構文を、JavaBeansの命名規則（getterメソッドとの関係）と関連付けて説明し、学生にJavaオブジェクトとテンプレート間のデータ結合の仕組みを深く理解させる。
次に、Webアプリケーション開発において避けて通れないセキュリティリスクであるクロスサイトスクリプティング（XSS）と、それに対するThymeleafの防御機構について解説する。 `th:text` 属性がデフォルトで提供するエスケープ処理（サニタイズ）の挙動、すなわち `<` や `>` といったHTML特殊文字が実体参照（`<`, `>` 等）に自動変換される仕組みを具体的なコード例を用いて説明する。これにより、悪意あるスクリプトの埋め込みを防ぐことができる点を強調し、セキュリティ意識を醸成する。一方で、意図的にHTMLタグを含む文字列をブラウザ上で解釈させたい場合に用いる `th:utext` （Unescaped Text）属性についても言及する。 `th:utext` を使用する場合のリスクと、使用すべき場面（例えば、信頼できるソースからのリッチテキスト表示など）を明確に区分けし、安易な使用を戒める指導を行う。これらの学習を通じて、学生は単にデータを表示するだけでなく、安全性と用途を考慮した適切な出力方法を選択できる能力を身につけることになる。この細目で理解すべき範囲は、変数式を用いた基本的なデータ表示から、 `th:text` と `th:utext` の挙動の違いによるサニタイズ処理の理解まで。
|
② 本細目では、テンプレートファイル内で定型的な文字列と動的な変数を組み合わせて表示するための手法や、表示時に簡易的な計算や比較を行うための演算子の利用について解説する。Webアプリケーションの画面表示においては、データベースから取得した値をそのまま表示するだけでなく、「ようこそ、〇〇さん」のように固定文言と結合したり、数値を通貨形式で表示したりといった加工が必要となる場面が多々ある。Javaのコード内で文字列結合を行ってからViewに渡すことも可能であるが、表示に関わる加工はViewの責務として扱うことがMVCモデルの分離原則において望ましい場合があることを説明する。
まず、基本的な文字列リテラルの記述方法と、演算子 `+` を用いた文字列結合について触れた後、Thymeleaf特有の強力な機能である「リテラル置換」について詳説する。パイプ記号 `|` で囲むことにより、 `+` 演算子を使用することなく、文字列と変数式を自然に混在させて記述できる構文（例: `|ようこそ、${name}さん|`）を紹介し、これによりテンプレートの可読性が著しく向上することを理解させる。また、テンプレート内で利用可能な算術演算子（`+`, `-`, `*`, `/`, `%`）について解説し、カウンターのインクリメントや単位変換などの軽微な計算処理をテンプレート側で行う方法を示す。さらに、比較演算子（`>`, `<`, `==` 等）を用いた論理判定についても扱うが、ここではHTML構文との競合という技術的な課題に触れる。 `<` などの記号がHTMLタグの開始として誤認される可能性があるため、HTML実体参照（`<`）や、Thymeleafが提供するエイリアス（`gt`, `lt`, `eq` 等）を使用する必要があることを具体例と共に解説する。加えて、条件演算子（三項演算子）を用いた簡易的な条件分岐による表示内容の切り替えについても触れ、 `th:if` などの制御構文を使用するまでもない単純な表示ロジックの記述方法を習得させる。これらの知識により、学生はView側で柔軟かつ可読性の高い表現を実装する能力を養う。この細目で理解すべき範囲は、リテラル置換による文字列構築から、各種演算子を用いたテンプレート内での基本的なデータ加工まで。
|
③ 本細目では、Webアプリケーションにおける画面遷移の要となるハイパーリンクの動的な生成方法と、Thymeleafにおけるパス解決の仕組みについて詳説する。静的なWebサイト制作においては、 `` タグの `href` 属性に相対パスや絶対パスを直接記述することでリンクを作成するが、動的なWebアプリケーション開発、特にJava Servlet/JSPやSpring Frameworkを用いた開発においては、アプリケーションのデプロイ先となるコンテキストパス（コンテキストルート）の扱いが課題となることをまず提示する。開発環境と本番環境でURLの階層構造が異なる場合や、コンテキストパスが変更された場合に、ハードコーディングされたパス記述はリンク切れの原因となり、保守性を著しく低下させる要因となることを理解させる。
この課題に対する解決策として、Thymeleafが提供する標準URL式 `@{...}` の構文と `th:href` 属性の使用方法を解説する。標準URL式を使用することで、Thymeleafエンジンが実行時に現在のコンテキストパスを自動的に検出し、URLの先頭に付与してくれる仕組み（URLリライティング）を詳説する。これにより、開発者はコンテキストパスの違いを意識することなく、アプリケーション内部のルートからのパス（例: `@{/user/list}`）を記述するだけで、環境に依存しない堅牢なリンクを生成できることを実践的に示す。また、詳細画面への遷移などで必要となる、動的なクエリパラメータを含んだURLの生成方法についても扱う。 `@{/path(param=${value})}` のような構文を用いることで、URLパラメータの結合やエンコーディング処理が自動的に行われる利便性を解説し、可読性と安全性の高いURL生成手法を習得させる。さらに、この標準URL式は `` タグのリンクだけでなく、 `` タグによるCSSファイルの読み込みや、 `![]() ` タグによる画像ファイルの表示（`th:src` 属性）など、外部リソースへの参照においても同様に適用される重要概念であることを説明する。これらの学習を通じて、学生はWebアプリケーションの構造変化に強い、柔軟な画面遷移とリソース管理を実装する能力を涵養する。この細目で理解すべき範囲は、標準URL式を用いたコンテキストパスの自動解決から、パラメータ付きURLおよび静的リソースへのリンク生成まで。
|
|
キーワード
|
① th:text ② 変数式 ③ サニタイズ ④ リテラル置換 ⑤ 標準URL式
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の講義で扱ったThymeleafの基本的な属性や式について、配布されたレジュメやノートを見返しながら整理すること。特に、Controllerから渡されたデータがどのようにHTML上に展開されるか、その際のセキュリティ上の配慮（サニタイズ）がどのようになされているかを確認すること。また、リテラル置換を用いた文字列結合や、標準URL式を用いたリンク生成の構文を紙に書き出すなどして、構文のルールを定着させること。静的なHTML記述とThymeleafによる動的な記述の違いを明確に意識して振り返りを行うこと。
◆次回授業の予習
次回はThymeleafを用いたより高度な画面表示ロジックとして、繰り返し処理や条件分岐について学ぶ。プログラミング言語における `for` 文や `if` 文に相当する制御構文が、テンプレートエンジン上でどのように表現されるか、一般的な概念として確認しておくこと。また、リスト形式のデータや真偽値（boolean）を持つデータを扱う際、View側でどのような処理が必要になるか想像しておくこと。プログラミングの基礎として学習した制御構造のロジックを再確認し、それをHTMLタグの属性として記述するイメージを持って授業に臨むこと。
|
|
19
|
Thymeleafの実践②
|
科目の中での位置付け
|
本講義は、Webアプリケーション開発演習における「Web表示層の開発」フェーズの中核を成す回である。前回学んだThymeleafによる基本的な変数の表示やリンク生成に加え、本回では繰り返し処理や条件分岐といった制御構文を習得する。これにより、データベースから取得した複数件のデータを一覧表示したり、ユーザの状態に応じて画面表示を切り替えたりする動的なWebページの構築が可能となる。実用的なアプリケーションのユーザーインターフェースを実装するための必須技術を確立する位置づけにある。
|
|
|
コマ主題細目
|
① 繰り返し処理の実装（th:each） ② 条件分岐の実装（th:if, th:unless） ③ 多分岐処理とループ状態の利用（th:switch, ステータス変数）
|
|
細目レベル
|
① 本細目では、Javaのコレクションフレームワークで管理された複数のデータを、HTML上で動的に展開するための繰り返し処理について詳説する。Webアプリケーションにおいて、データベース検索結果の一覧表示や、ショッピングカート内の商品リスト表示など、不定数のデータを扱う場面は極めて頻繁に発生する。Thymeleafにおいてこれらを実現するのが、`th:each`属性である。授業ではまず、Controllerクラスにおいて`java.util.List`等のコレクションオブジェクトを生成し、Modelインターフェースを通じてViewに受け渡す一連のデータフローを再確認する。その上で、View側での具体的な記述方法として、`th:each="変数名 : ${コレクション名}"`という構文の構造を論理的に解説する。ここで重要なのは、この属性が付与されたHTML要素そのものが、コレクションの要素数分だけ繰り返されるというDOM（Document Object Model）操作の挙動を理解することである。具体的には、HTMLのtableタグを用いた表形式のデータ表示を例題として取り上げる。trタグに`th:each`を適用し、その内部のtdタグで個々の要素のプロパティ（例えばUserオブジェクトのnameやageなど）を展開する実践的なコーディングを行う。また、ネストされた構造や、List以外のIterableなオブジェクト（配列やMapなど）に対する挙動についても触れ、Javaの拡張for文との類似性を比較しながら学生の理解を促進する。さらに、繰り返し処理における変数のスコープ、つまり定義されたローカル変数がどの範囲のHTML要素内で参照可能であるかについても言及し、可読性と保守性の高いテンプレート記述の能力を涵養する。これにより、静的なHTMLモックアップから、動的なデータ駆動型のWebページへと昇華させるための基礎技術を定着させる。
この細目で理解すべき範囲は、Controllerから渡されたList型のデータを`th:each`を用いてHTMLの要素として繰り返し展開し、各要素のプロパティを表示する手法まで。
|
② 本細目では、画面表示の制御において不可欠な条件分岐のロジックを、Thymeleafを用いて実装する方法について解説する。Webアプリケーションでは、ログイン状態の有無によって「ログイン」ボタンと「ログアウト」ボタンを出し分けたり、データの有無によってメッセージを変更したりするなど、コンテキストに応じた表示の切り替えが求められる。これを実現するのが`th:if`および`th:unless`属性である。授業では、まず`th:if`属性の基本的な評価メカニズムについて講義する。属性値として記述された式が真（true）と評価された場合にのみ、そのHTML要素（およびその子要素）がレンダリングされ、偽（false）の場合にはDOMツリーから完全に削除されるという挙動を、HTMLソースコードのレベルで確認させる。これはCSSの`display: none`による非表示とは異なり、ブラウザに送信されるHTML自体から要素が排除されるため、セキュリティや転送量の観点からも重要であることを強調する。次に、`th:unless`について解説する。これは`th:if`の対義的な動作、すなわち条件が偽（false）の場合に要素を表示する属性である。Javaのif-else文とは異なり、Thymeleafではelse属性が存在しないため、`th:if`と`th:unless`を組み合わせて排他的な表示制御を行うパターンを習得させる。また、条件式の記述において、比較演算子（>, <, ==, !=）や論理演算子（and, or, not）の使用方法、さらにはnullチェックや空文字の評価といったThymeleaf特有の真偽値評価ルール（Truth Evaluation）についても触れる。演習では、年齢データに基づいた表示内容の変更や、リストが空の場合の「データがありません」というメッセージ表示の実装などを通じて、動的な表示制御の実践能力を高める。
この細目で理解すべき範囲は、`th:if`および`th:unless`を用いて条件に応じたHTML要素の生成・削除を制御し、比較演算子や論理演算子を用いた適切な条件式を記述する手法まで。
|
③ 本細目では、より複雑な表示ロジックに対応するための多分岐処理と、繰り返し処理におけるメタデータの利用方法について詳説する。まず、Javaのswitch文に相当する`th:switch`および`th:case`属性について解説する。`th:if`を多用して複数の条件を記述することは、コードの可読性を低下させる要因となる。そこで、一つの評価対象に対して複数のパターンで分岐を行う場合に適した`th:switch`の構文構造を学ぶ。親要素に`th:switch`を定義し、子要素に`th:case`で値を指定することで、一致する要素のみを表示する仕組みを理解させる。特に、どのcaseにも当てはまらない場合のデフォルト処理として`th:case="*"`という記述方法があることを示し、Java言語との親和性を確認しながら学習を進める。次に、繰り返し処理の高度な利用法として、ループの状態（ステータス）を管理する変数の利用について解説する。`th:each`では、反復変数に加え、第2引数としてステータス変数を定義することが可能である。このステータス変数が保持するプロパティ、具体的には現在のインデックス（index）、1から始まるカウント（count）、コレクションの総数（size）、最初や最後の要素であるかの真偽値（first, last）、偶数奇数の判定（even, odd）などの活用法を具体的なコード例とともに提示する。例えば、テーブルの行に縞模様（ストライプ）を適用するために`odd`や`even`を利用してCSSクラスを切り替える手法や、リストの通し番号を表示するために`count`を利用する手法などを演習する。これらの機能は、ユーザーにとって視認性の高いUIを構築する上で実用的な技術であり、単なるデータの羅列にとどまらない表現力を学生に習得させることを目的とする。
この細目で理解すべき範囲は、`th:switch`を用いた多分岐による表示切り替えの実装と、`th:each`のステータス変数を利用してループ中のインデックスや偶奇判定などのメタ情報を活用する手法まで。
|
|
キーワード
|
① th:each ② th:if ③ th:unless ④ th:switch ⑤ ステータス変数
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で学んだThymeleafの制御構文（繰り返し、条件分岐）について、配布されたサンプルコードや演習課題のコードを見直し、それぞれの属性がHTMLのレンダリング結果にどのような影響を与えているかをブラウザの「ページのソースを表示」機能を用いて確認すること。特に、`th:if`で条件が偽になった場合にHTMLタグ自体が消滅している点や、`th:each`によってタグが複製されている様子を視覚的に再確認し、サーバーサイドでの処理結果がクライアントサイドにどう渡るかを整理しておくこと。
◆次回授業の予習
次回は、Thymeleafにおける画面レイアウトの共通化（部品化）について学習する。Webサイトにおいて、ヘッダーやフッター、サイドメニューなどの共通部分をどのように管理すべきか、一般的なWeb制作の観点から考察しておくこと。また、プログラミングにおける「関数の再利用」や「モジュール化」の概念を振り返り、HTMLの断片を部品として扱うことのメリット（保守性の向上や修正漏れの防止など）について整理しておくこと。特段の環境構築は不要である。
|
|
20
|
Thymeleafの実践③
|
科目の中での位置付け
|
本講義は、Webアプリケーション開発演習の第20回目であり、第4部「Web表示層の開発」の総仕上げに位置付けられる。前回までに習得したThymeleafの基本構文や制御構造を基に、今回は実務的なアプリケーション開発において不可欠な「画面の共通化」と「レイアウト管理」の手法を学ぶ。これにより、コードの重複を排除し、保守性と拡張性に優れたView層を構築するための実践的なスキルを確立する。
|
|
|
コマ主題細目
|
① フラグメントによる画面部品の共通化 ② 部品へのデータ受け渡しと動的表示 ③ ベースレイアウトによる統一的な画面構築
|
|
細目レベル
|
① Webアプリケーションには、ヘッダー、フッター、サイドメニューなど、複数の画面で共通して表示される要素が存在する。これらのHTMLコードを各画面ファイルに個別に記述すると、修正が必要になった際にすべてのファイルを更新しなければならず、保守性が著しく低下するだけでなく、記述ミスの原因ともなる。本細目では、こうした問題を解決するためにThymeleafが提供する「フラグメント（Fragment）」機能について詳説する。まず、共通部分を独立したHTMLファイルとして切り出し、th:fragment属性を用いて部品として定義する方法を解説する。例えば、ヘッダー部分のみを記述したHTMLファイルを作成し、そのルート要素に一意の名前を付与することで、外部から呼び出し可能なコンポーネントとして定義できることを示す。次に、作成した部品を他の画面から呼び出すためのth:insert属性およびth:replace属性の使用方法について学習する。これらは指定したパスにあるテンプレートの特定のフラグメントを、現在のHTML内に取り込む機能を持つが、両者には生成されるDOM（Document Object Model）構造において決定的な違いがあることを理解させる。具体的には、th:insertは呼び出し元のタグの内側に部品を挿入するのに対し、th:replaceは呼び出し元のタグそのものを部品のタグで置き換えるという挙動の違いを、具体的なHTML構造の変化を例示しながら丁寧に解説する。また、パスの指定方法として、同一ファイル内のフラグメントを参照する場合や、別ディレクトリにあるファイルを指定する場合の構文についても触れ、プロジェクト構成に応じた適切な記述方法を習得させる。これにより、学生は「DRY（Don't Repeat Yourself）」の原則に基づいた、重複のない効率的なテンプレート管理の基礎を理解する。この細目で理解すべき範囲は、th:fragmentによる部品定義から、th:insertおよびth:replaceを用いた基本的な部品の取り込み方法まで。
|
② 前項で学んだ静的な部品化に加え、実際の開発では「呼び出し元の画面に応じて表示内容を一部変更したい」という要求が頻繁に発生する。例えば、ヘッダー内のページタイトルを表示する部分や、ナビゲーションバーで現在表示中のメニューをハイライトする場合などがこれに該当する。本細目では、フラグメントに対して引数（パラメータ）を渡し、動的に表示内容を制御する方法について解説する。Thymeleafのフラグメントは、関数のように引数を受け取ることが可能であり、th:fragment属性の定義において変数名を宣言することで、呼び出し元から任意の値を受け取ることができる仕組みを詳説する。具体的には、部品側でth:fragment="header(title)"のように引数を定義し、呼び出し側でth:replace="header :: header('トップページ')"のように値を渡す構文を学ぶ。渡された値は、部品内のテンプレートにおいて通常の変数と同様に扱うことができ、th:text属性などで出力したり、条件分岐（th:if）の判定に使用したりすることが可能であることを示す。また、リテラル（固定文字列）だけでなく、呼び出し元のModelに含まれる変数をそのまま転送する方法や、複数の引数を渡す場合の記述ルールについても触れる。さらに、引数を省略した場合の挙動や、ローカル変数のスコープ（有効範囲）についても解説し、部品の独立性を保ちながら柔軟な表示を実現するための設計指針を提示する。これにより、単なる定型文の埋め込みにとどまらず、コンテキストに応じた再利用性の高いUIコンポーネントを作成する能力を養う。この細目で理解すべき範囲は、フラグメントに対する引数の定義、呼び出し時のパラメータ指定、および受け取った変数を利用した動的なHTML生成まで。
|
③ 個別の部品化に続き、Webアプリケーション全体の統一感を保ち、開発効率を最大化するための「ベースレイアウト」の作成手法について解説する。多くのWebページは、DOCTYPE宣言、htmlタグ、headタグ（meta情報やCSS/JavaScriptの読み込み）、bodyタグといった基本的な骨格を共有している。ページごとにこれらの構造を記述することは冗長であり、共通のスタイルシートの変更やスクリプトの追加が必要になった際に多大な修正コストが発生する。本細目では、こうした共通の骨格を「ベースレイアウト」として一つのファイルに集約し、各ページ固有のコンテンツ（メイン部分）のみを個別に作成してレイアウトに埋め込む手法を習得する。具体的には、th:replace属性の高度な利用法として、フラグメント式を用いたレイアウトの適用方法を詳説する。ベースレイアウト側では、ページごとに差し替えたい部分（例えばメインコンテンツ領域）にプレースホルダとなるタグを用意し、th:replace属性を用いて呼び出し元から渡されたフラグメントで置換する仕組みを構築する。一方、個別ページ側では、ベースレイアウトを呼び出しつつ、自身のコンテンツ部分を引数として渡す記述を行う。この際、特別な属性であるth:fragmentを使わずに、CSSセレクタのような形式で現在のページの特定部分をフラグメントとして渡すテクニックについても触れる。これにより、開発者は各画面の実装において、共通のデザインや設定を意識することなく、コンテンツの作成に集中できるようになることを理解させる。また、タイトルや追加のCSSファイルなど、body以外の要素も個別に指定してレイアウトに反映させる方法を学び、柔軟かつ堅牢な画面設計の基盤を構築する能力を涵養する。この細目で理解すべき範囲は、共通レイアウトファイルの作成、フラグメント式を用いたレイアウトの適用、およびコンテンツの差し込み実装まで。
|
|
キーワード
|
① th:fragment ② th:replace ③ th:insert ④ ベースレイアウト ⑤ コンポーネント化
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で学んだフラグメントの定義方法と呼び出し方の違い（replaceとinsert）について、手元のノートや配布資料を見ながら整理してください。特に、ヘッダーやフッターなどの共通部分をどのように切り出し、どのように統合するかという一連の流れを頭の中でシミュレーションすることが重要です。また、ベースレイアウトの仕組みについて、親テンプレートと子テンプレートの関係性を図解して確認し、データの受け渡しがどのように行われているかを復習してください。
◆次回授業の予習
次回はクライアント（ブラウザ）からサーバーへデータを送信する方法について学びます。Webにおけるフォーム（form）の役割と、HTTPリクエストの仕組みについて基本的な用語を確認しておいてください。特に、HTMLのinputタグやsubmitボタンがどのような動作をするのか、およびGETリクエストとPOSTリクエストの違いについて、これまでの知識を振り返っておくと、次回の講義内容（リクエストパラメータの取得）がスムーズに理解できます。
|
|
21
|
クライアントからのデータ受信（リクエストパラメータ）
|
科目の中での位置付け
|
本講義は、Webアプリケーション開発における「入力処理」の基礎を学ぶ重要な回である。これまでの講義では、サーバーからクライアントへのデータ表示（出力）を中心に学習してきたが、本回からはクライアントからサーバーへのデータ送信（入力）を扱う。これにより、ユーザーのアクションに応答する双方向の対話的なアプリケーション構築が可能となる。Spring MVCにおける基本的なデータ受信方法を習得することは、後のフォーム処理やデータベース連携の基盤となる不可欠なステップである。
|
|
|
コマ主題細目
|
① リクエストパラメータの概念とWebにおけるデータ送信の仕組み ② Spring MVCにおける@RequestParamアノテーションの活用 ③ GETメソッドとPOSTメソッドによるデータ受信の実践
|
|
細目レベル
|
① 本細目では、Webアプリケーションにおいてクライアント（Webブラウザ）からサーバーへデータを送信するための基本的な仕組みである「リクエストパラメータ」について、その概念と構造を体系的に解説する。まず、Webブラウザ上でユーザーが入力したデータが、どのような形式でサーバーに送信されるかをHTTPプロトコルのレベルで理解させる。具体的には、HTMLのフォーム（formタグ）内に配置された入力要素（inputタグやselectタグなど）において、name属性がデータの「キー」となり、ユーザーが入力した内容が「値」となる「キーと値のペア」として管理される仕組みを詳説する。このname属性がサーバー側でデータを識別するための唯一の手がかりとなるため、HTML記述におけるname属性の重要性を強調する。
次に、データの送信方法として、HTTPリクエストにおけるGETメソッドとPOSTメソッドの違いによるパラメータの格納場所の差異について理論的に説明する。GETメソッドを用いた場合、リクエストパラメータはURLの末尾に「?キー=値」という形式で付与されることを解説する。この形式は「クエリストリング」または「クエリ文字列」と呼ばれ、複数のパラメータを送る場合には「&」記号で連結されるという文法規則を確認する。一方、POSTメソッドを用いた場合、データはHTTPリクエストの「リクエストボディ」内部に格納されて送信されるため、URL上には現れないことを説明する。これは、パスワードなどの機密情報を扱う際や、大量のデータを送信する際に適しているという特性を、既習のHTTP通信の知識と紐づけて再確認させる。
また、これらのデータ送信メカニズムが、Spring Frameworkのようなサーバーサイド技術によってどのように抽象化され、処理されるかの導入を行う。従来のServlet開発においては、HttpServletRequestオブジェクトからgetParameterメソッドを用いて文字列として手動で取得する必要があったが、フレームワークを利用することでこれらの処理がどのように簡素化されるかという視点を持たせ、次項のアノテーション学習への動機付けを行う。ここでは、あくまでHTTP通信の原理原則に基づいたデータの流れを理解することに主眼を置き、Webアプリケーションにおける「入力」の背後にある技術的構造を学生に把握させることを目的とする。この細目で理解すべき範囲は、リクエストパラメータの定義から、HTTPメソッドによる送信形式の違い、およびHTMLフォームにおけるname属性の役割まで。
|
② 本細目では、Spring MVCが提供するデータ受信のための核心的な機能である「@RequestParam」アノテーションについて、その仕様と利用方法を詳細に解説する。前項で学習したHTTPリクエストパラメータを、Javaのメソッド引数として直接受け取るためのマッピング機構（データバインディング）について、具体的なコード構造を交えて説明する。Controllerクラスのメソッド引数に対して@RequestParamアノテーションを付与することで、Spring Frameworkが自動的にリクエストパラメータの中から指定された名称（name属性の値）に一致するデータを探し出し、その値を引数に注入する仕組みを理解させる。
特に重要な点として、Spring Frameworkによる「型変換」の機能について詳説する。HTTP通信上ではすべてのパラメータは「文字列（String）」として送信されるが、Spring MVCは受け取る引数の型（intやInteger、LocalDateなど）に合わせて、可能な限り自動的に型変換を行ってくれる。これにより、開発者が手動で文字列から数値へ変換するパース処理（Integer.parseIntなど）を記述する必要がなくなり、コードの可読性と保守性が大幅に向上することを理解させる。
さらに、@RequestParamアノテーションが持つオプション属性についても深く掘り下げる。まず、引数名とリクエストパラメータ名が異なる場合に使用する「name」属性の指定方法を解説する。次に、必須チェックを制御する「required」属性について説明する。デフォルトではrequired属性はtrueとなっており、該当するパラメータが送信されない場合は「400 Bad Request」エラーが発生する仕様であることを認識させる。その上で、任意の入力項目を扱うためにrequiredをfalseに設定する方法や、パラメータが未送信の場合にデフォルト値を設定する「defaultValue」属性の活用法について解説する。これにより、堅牢で柔軟な入力処理を実装するための基礎能力を養う。これらの機能を通じて、Spring Frameworkがいかにしてボイラープレートコード（定型的なコード）を排除し、開発者がビジネスロジックに集中できる環境を提供しているかを学術的な視点から理解させる。この細目で理解すべき範囲は、@RequestParamアノテーションの基本的な使い方から、型変換の仕組み、および各オプション属性（name, required, defaultValue）の詳細な仕様まで。
|
③ 本細目では、これまでに学習した理論とアノテーションの知識を統合し、実際に動作するWebアプリケーションを作成することで、クライアントからのデータ受信処理を実践的に習得させる。具体的には、入力画面（HTML/Thymeleaf）、処理を行うController、結果を表示する出力画面の一連の流れを構築する演習を行う。まず、Spring Bootプロジェクトを作成し、Controllerクラスにおいてリクエストパラメータを受け取るメソッドを実装する手順を解説する。ここでは、Modelインターフェースを利用して、受け取ったデータをビュー（画面）へ渡す処理も組み込み、入力から出力までのデータのライフサイクルを完結させる。
演習では、GETメソッドとPOSTメソッドの双方を用いたデータ送信を実装し、それぞれの挙動の違いを検証する。GETメソッドの演習では、リンク（aタグ）を用いたパラメータ送信を行い、ブラウザのアドレスバーにクエリストリングが表示される様子を確認させる。これにより、URLを通じてデータが渡される仕組みを視覚的に理解させる。一方、POSTメソッドの演習では、HTMLフォーム（formタグ）を作成し、method属性を"POST"に指定してデータを送信する。この際、ブラウザのアドレスバーにはデータが表示されず、内部的にデータが送信されていることを確認し、セキュリティや用途に応じたメソッドの使い分けの重要性を再認識させる。
また、受け取ったデータをThymeleafを用いて画面に表示する方法についても復習を兼ねて実践する。Controllerで受け取った値が正しくModelに格納され、遷移先のHTMLファイルで変数が展開されて表示されるまでのプロセスを追跡することで、MVCモデルにおけるデータの流れ（View -> Controller -> Model -> View）を体感させる。さらに、意図的にパラメータを送信しないケースや、不正な型（数値項目に文字を入力するなど）を送信したケースを試し、Spring MVCがどのような反応（エラー画面や例外）を示すかを確認することで、例外処理やバリデーションの必要性への気付きを促す（これらは後の回で詳細に学ぶが、ここでは挙動の確認にとどめる）。この実践を通じて、Webアプリケーションにおける基本的なインタラクションの実装能力を確実なものとする。この細目で理解すべき範囲は、リクエストパラメータを受け取るControllerの実装から、GET/POSTによる挙動の差異の確認、および画面表示までの実装プロセスまで。
|
|
キーワード
|
① リクエストパラメータ ② @RequestParam ③ クエリストリング ④ POSTメソッド ⑤ GETメソッド
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で学んだリクエストパラメータの概念と、Spring MVCにおける取得方法について振り返りを行ってください。特に、Webブラウザから送信されたデータがどのような経路と形式でサーバーに届き、それがアノテーションによってどのようにJavaの変数に変換されるか、その一連の流れを頭の中で整理してください。また、GETメソッドとPOSTメソッドの違いが、実際のデータ送信においてどのように現れるか（URLへの表示有無など）を再確認し、それぞれの用途について整理しておくことが重要です。
◆次回授業の予習
次回の授業では、複数の入力項目をより効率的に扱うための「Formクラス」によるデータバインディングについて学習します。これに備えて、Javaにおけるクラスの定義方法、特にフィールド（メンバ変数）の宣言と、それらにアクセスするためのアクセサメソッド（Getter/Setter）の役割について復習しておいてください。また、オブジェクト指向におけるカプセル化の概念を再確認しておくと、次回学ぶFormクラスの仕組みをよりスムーズに理解することができます。Spring Frameworkがどのようにオブジェクトを利用してデータをまとめるかという点を意識して準備してください。
|
|
22
|
Formクラスによるデータバインディング
|
科目の中での位置付け
|
本講義は、Spring Frameworkを用いたWebアプリケーション開発演習の第22回目であり、第4部「Web表示層の開発」の中盤に位置します。前回学習した`@RequestParam`による個別のリクエストパラメータ取得手法を発展させ、実務的なWebフォーム開発において不可欠となる「Formクラス」を用いた効率的なデータ受信方法を習得します。これは、後の第6部で実施するToDoアプリ開発におけるデータ登録・更新処理の基盤となる重要な技術要素です。
|
|
|
コマ主題細目
|
① 多数のリクエストパラメータ処理における課題とデータバインディングの概念 ② Formクラスの定義と実装およびLombokの活用 ③ ControllerにおけるFormクラスの利用とデータ処理フロー
|
|
細目レベル
|
① Webアプリケーション開発において、クライアントからサーバーへのデータ送信は頻繁に行われる操作であり、そのデータ構造は多岐にわたります。前回までの授業では、HTTPリクエストに含まれるパラメータを`@RequestParam`アノテーションを用いて個別に取得する方法を学習しました。この方法は、検索キーワードやIDなど、単一または少数のパラメータを扱う場合には直感的で分かりやすく、コード記述量も少ないため有効です。しかし、実際の業務アプリケーションにおける「ユーザー登録画面」や「お問い合わせフォーム」、「商品登録画面」などを想像してみると、入力項目が数十個に及ぶことは珍しくありません。このような多項目のフォームデータをすべて`@RequestParam`を用いて個別に受け取ろうとすると、Controllerクラスのメソッド引数がパラメータの数だけ増大することになります。例えば、氏名、住所、電話番号、メールアドレス、年齢、性別などを受け取る場合、メソッドのシグネチャ（定義）は非常に長く複雑なものとなり、可読性が著しく低下します。また、将来的に入力項目が追加・変更された場合、メソッドの引数定義を修正する必要が生じ、それに伴う修正漏れやバグの温床となるリスクが高まります。このような、パラメータ数の増加に伴うコードの複雑化と保守性の低下という課題を解決するために、Spring Frameworkなどの現代的なWebフレームワークでは「データバインディング」という仕組みが提供されています。データバインディングとは、HTTPリクエストとして送信された複数のパラメータを、Javaのオブジェクト（クラスのインスタンス）のフィールドに自動的に割り当てる（バインドする）機能のことを指します。この仕組みを利用することで、開発者は個々のパラメータを解析して変数に代入するという煩雑な手続き記述から解放され、関連するデータを一つのオブジェクトとしてまとめて扱うことが可能になります。本細目では、パラメータが増大した際の手続き型的な処理の限界を理解し、オブジェクト指向的なアプローチであるデータバインディングの概念とその利点について、具体的なシナリオと比較を通じて深く理解を促します。この細目で理解すべき範囲は、多数のパラメータを個別に扱う際の問題点と、それを解決するデータバインディングの基本概念まで。
|
② データバインディングを実現するために、Spring MVCではデータを受け取るための専用のクラスを作成します。これを一般的に「Formクラス」と呼びます。Formクラスは、画面上の入力フォームに対応した構造を持つJavaクラスであり、基本的にはPOJO（Plain Old Java Object）として定義されます。Formクラスの実装において最も重要なルールは、HTMLフォーム内の各入力項目（``タグなど）の`name`属性の値と、Formクラスのフィールド変数名を一致させることです。Spring Frameworkは、リクエストパラメータの名前とFormクラスのフィールド名を照合し、一致するものがあればその値を自動的にセットします。この自動的な値のセットを行うためには、各フィールドに対するアクセサメソッド（GetterおよびSetter）が必要となります。Javaの標準的な仕様であるJavaBeans規約に従い、SpringはSetterメソッドを呼び出すことで値を注入するためです。ここで、第2部の「Javaの基礎知識」および「開発支援ツール」で学習したLombokライブラリが大きな威力を発揮します。Formクラスは単にデータを保持するだけのクラスであるため、手動でGetterやSetter、`toString`メソッドなどを記述することは、ボイラープレートコード（定型コード）の増大を招きます。そこで、クラス定義にLombokの`@Data`アノテーションを付与することで、これらの必須メソッドをコンパイル時に自動生成させることができます。これにより、Formクラスのソースコードはフィールド定義のみの非常に簡潔な状態に保たれ、可読性と保守性が大幅に向上します。また、SpringがFormクラスのインスタンスを生成する際には、デフォルトコンストラクタ（引数なしコンストラクタ）が使用されることが一般的です。したがって、コンストラクタの定義に関しても注意が必要ですが、Lombokを使用している場合は適切にハンドリングされるか、必要に応じて`@NoArgsConstructor`などを併用する知識も実践的には有用です。さらに、Formクラスのフィールドの型（String, int, booleanなど）に合わせて、送信された文字列データからの型変換もSpringが自動的に試みます。例えば、HTMLから送信されるデータはすべて文字列ですが、Formクラスのフィールドが`int`型であれば、数値への変換が行われてセットされます。本細目では、これらのFormクラス作成におけるルールとLombok活用のメリットを、コード記述の実践を通じて定着させます。この細目で理解すべき範囲は、Formクラスの作成ルール、フィールド名とname属性の一致、およびLombokを用いた実装方法まで。
|
③ Formクラスを定義した後は、実際にControllerクラスのメソッドでそれを利用し、クライアントからのデータを受け取る処理を実装します。Spring MVCにおいて、Formクラスを利用したデータ受信の実装は驚くほどシンプルです。具体的には、リクエストを処理するControllerのメソッド（`@PostMapping`などが付与されたメソッド）の引数として、作成したFormクラスを宣言するだけです。従来のServlet開発のように`request.getParameter("name")`を繰り返す必要もなければ、前回学んだ`@RequestParam`を羅列する必要もありません。Spring Frameworkの内部動作としては、まずリクエストを受け取ったタイミングで、引数に指定されたFormクラスのインスタンスを生成（new）します。次に、HTTPリクエストに含まれるパラメータ名とFormクラスのフィールド名を照合し、一致する項目についてSetterメソッドを用いて値を格納していきます。この一連の処理が完了した状態で、Controllerのメソッドが呼び出され、引数のFormオブジェクトには既に画面からの入力値が詰まった状態となっています。これにより、開発者はメソッドの冒頭から、データが格納されたオブジェクト（Formオブジェクト）を使ってビジネスロジックの呼び出しやデータの加工を行うことができます。また、受け取ったFormオブジェクトは、そのまま次の画面（View）へ渡すモデルデータとしても利用可能です。さらに、Formクラスを利用することで、入力データの検証（バリデーション）を行う際にも、このクラスに対してアノテーションを付与する形でルールを一元管理できるようになります（バリデーションの詳細は後の講義で扱いますが、その基盤としてFormクラスが機能することを認識させます）。授業では、実際にHTMLフォームから複数のデータを送信し、Controller側でFormクラスとして受け取り、その内容をコンソールに出力したり、完了画面に表示したりする演習を行います。この演習を通じて、ブラウザからサーバーへ、そしてJavaオブジェクトへとデータが流れるプロセスと、Springがその間をどのように自動化しているかを体感させます。Formクラスの導入によって、Controllerのコードがいかにスッキリとし、変更に強い構造になるかを、`@RequestParam`を用いた場合と比較しながら解説し、実務における標準的な実装パターンとしての定着を図ります。この細目で理解すべき範囲は、ControllerでのFormクラス受け取り記述、内部的なデータバインディングのフロー、およびその実践的メリットまで。
|
|
キーワード
|
① Formクラス ② データバインディング ③ POJO ④ @Data ⑤ JavaBeans規約
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で学習したFormクラスを用いたデータ受信の流れについて、自分の言葉で整理してください。特に、HTML側の`name`属性とJavaクラス側のフィールド名が一致していなければならない理由や、Lombokの`@Data`アノテーションがどのような役割を果たしているかについて、ノートに要点をまとめてください。また、これまでに作成した単純な入力フォームのコードを見直し、もし項目数が10個に増えた場合にコードがどのように変化するかを想像してみることで、Formクラスの有用性を再確認してください。
◆次回授業の予習
次回の授業では、URLの一部を変数として扱う「パス変数」について学習します。Webサイトを利用する際、URLの末尾にIDのような数字が含まれているページ（例：商品詳細ページやユーザープロフィールページなど）を見たことがあるはずです。普段利用しているWebサービスにおいて、画面遷移に伴ってURLがどのように変化しているか観察しておいてください。また、HTTPリクエストにおいて、今回学んだ「リクエストパラメータ（クエリ文字列やPOSTデータ）」と「URLパス」が概念的にどのように異なるかについて、簡単に調べておいてください。
|
|
23
|
URLパス変数の利用
|
科目の中での位置付け
|
本講義は、クライアントからサーバーへデータを送信する手法の第3弾として、URLの一部を変数として扱う技術を扱います。前回までに学習したリクエストパラメータやフォームデータが、検索条件や入力情報の送信に適しているのに対し、今回学習するURLパス変数は、特定のリソース（データ）を一意に識別するためのIDなどを送信する際に標準的に用いられる手法です。これにより、一覧画面から詳細画面への遷移や、特定のデータに対する更新・削除処理の呼び出しといった、Webアプリケーションにおいて頻出する機能を実装するための基礎技術が完結します。
|
|
|
コマ主題細目
|
① URLパス変数の概念とControllerにおける受信設定 ② Thymeleafによるリンク生成と動的パスの構築 ③ フォームボタンによるパス変数の利用とパラメータとの使い分け
|
|
細目レベル
|
① 本細目では、URLの一部を動的な値として扱う「URLパス変数」の概念と、それをSpring MVCのコントローラで受け取るための実装方法について詳説します。Webアプリケーションにおいて、サーバー上の特定のリソースにアクセスする際、その識別子をURLのパスの一部として組み込む設計は広く採用されています。例えば、会員IDが10番のユーザー詳細情報を表示する場合、「/detail?id=10」のようにクエリストリングを用いる方法と、「/detail/10」のようにURLの階層構造の一部としてIDを含める方法が存在します。後者は、URL自体がリソースの住所を示すという考え方に基づき、可読性が高く、検索エンジン最適化（SEO）の観点でも有利であるとされています。Spring Frameworkでは、このようなURL設計を容易に実現するための機能が提供されています。
具体的には、コントローラのハンドラメソッドに付与するマッピングアノテーション（@GetMappingや@PostMappingなど）において、URLの一部を波括弧「{}」で囲むことで、その部分をプレースホルダ（変数）として定義します。例えば、「/detail/{id}」と記述した場合、この「{id}」の部分には任意の文字列や数値が入ることが許容され、その実際の値がプログラム内で利用可能となります。この可読性の高いURLから値を取り出すために使用されるのが、「@PathVariable」アノテーションです。ハンドラメソッドの引数に対してこのアノテーションを付与することで、Spring MVCはリクエストされたURLの該当箇所から値を抽出し、自動的に引数にバインドします。この際、URL上の値は文字列ですが、メソッドの引数がInteger型などの数値型であれば、Springが自動的に型変換を行います。ただし、URLテンプレート内の変数名とメソッドの引数名は一致している必要があります。もし異なる名前を使用する場合は、アノテーションの引数で明示的に名前を指定する必要があります。この一連の仕組みを理解することで、学生は静的なURLだけでなく、動的に変化するURLパターンに対応した柔軟なコントローラを実装できるようになります。また、この技術は後の回で学ぶRESTfulなAPI設計や、CRUD操作（特に更新や削除対象の指定）の実装において不可欠な要素となります。
この細目で理解すべき範囲は、URLパス変数の役割と、@RequestMappingおよび@PathVariableアノテーションを用いた値の取得方法まで。
|
② 本細目では、ビュー層であるThymeleafにおいて、動的なURLパス変数を含むリンクを生成する方法について解説します。前項でコントローラ側の受け入れ態勢が整ったとしても、クライアント側から適切な形式のURLでリクエストを送信しなければ機能は成立しません。特に、データベースから取得した一覧データなどを表示する際、各行に「詳細」ボタンやリンクを配置し、それぞれのデータのIDをURLパスに埋め込む処理は極めて頻繁に行われます。Thymeleafでは、標準のHTML属性を動的に処理するための「th:href」属性を提供しており、これを用いてコンテキストパスを考慮したリンクURLを生成します。
特筆すべきは、Thymeleaf独自のリンク式「@{...}」の構文におけるパラメータの扱いです。通常のリクエストパラメータ（クエリストリング）を生成する場合は、「@{/path(param=${value})}」のように記述しますが、パス変数を埋め込む場合は、URLパス内のプレースホルダとパラメータを対応付ける記述を行います。具体的には、「@{/detail/{id}(id=${user.id})}」のように記述することで、Thymeleafは括弧内で指定された変数「id」の値を、パス内の「{id}」部分に置換してURLを生成します。この機構により、テンプレートファイル内では抽象的なパス構造を維持しつつ、実行時には具体的なデータに基づいた正しいURLが生成されます。
授業では、実際にModel経由で渡されたオブジェクトのプロパティ（IDなど）を使用して、動的にリンクを生成する演習を行います。例えば、会員一覧画面において、各会員の名前をリンク化し、クリックするとその会員のIDを含んだURL（例：/member/5）へ遷移するような実装を通じて、構文の理解を深めます。また、URL構築においては、文字列結合演算子を用いる方法も考えられますが、Thymeleafのリンク式を用いることで、URLエンコーディングなどの処理が適切に行われる利点があることも触れます。これにより、学生はハードコーディングされた静的なリンクではなく、アプリケーションの状態やデータに応じて動的に変化するナビゲーションを構築する能力を養います。これは、ユーザーインターフェースの実装において、画面間の連携を実現するための核心的な技術となります。
この細目で理解すべき範囲は、Thymeleafのリンク式を用いたパス変数を含むURLの生成方法と、HTMLアンカータグへの適用まで。
|
③ 本細目では、リンク（アンカータグ）だけでなく、フォームやボタンを用いた遷移におけるパス変数の利用方法と、リクエストパラメータとの適切な使い分けについて解説します。Webアプリケーションのユーザーインターフェースでは、単なるテキストリンクだけでなく、ボタン形式での画面遷移が求められる場面が多々あります。HTMLのformタグを使用する場合、送信先URLを指定する「action」属性に対しても、Thymeleafの「th:action」属性を用いることで、前項と同様のリンク式「@{...}」を適用可能です。これにより、例えば「削除」ボタンを押した際に、「/delete/{id}」のような特定のリソースに対する操作用URLへリクエストを送信することが可能になります。授業では、詳細画面への遷移をボタンで行うケースなどを題材に、formタグを用いたGETリクエストの構築方法を実践します。
さらに、本講義の重要なテーマとして、第21回・第22回で学んだ「リクエストパラメータ（@RequestParam）」と、今回学んだ「パス変数（@PathVariable）」の使い分けの指針について理論的な整理を行います。技術的にはどちらを用いてもサーバーに値を渡すことは可能ですが、設計上の意味合い（セマンティクス）が異なります。一般的に、パス変数は「リソースの識別」に用いられます。つまり、その値がなければリソース自体が特定できないような、必須かつ主たる情報（IDなど）を扱う場合に適しています。一方、リクエストパラメータは「リソースの操作やフィルタリング」に用いられます。検索条件、ソート順、ページ番号など、その値がなくてもリソース自体は存在するが、表示形式や範囲を限定するための付加的な情報を扱う場合に適しています。
この使い分けを理解することは、単に機能するだけでなく、分かりやすくメンテナンス性の高いURL設計を行うために重要です。授業では、具体的なシナリオ（例：商品詳細ページへのアクセスはパス変数、商品一覧の価格絞り込みはリクエストパラメータ）を提示し、どちらを採用すべきかを議論・解説することで、学生の設計能力を涵養します。また、これらの知識は、将来的にRESTful APIなどのより高度なWebサービス設計を学ぶ際の基礎概念として直結します。最終的に、学生は要件に応じて最適なデータ送信方式を選択し、Spring MVCの機能を適切に組み合わせて実装できるようになることを目指します。
この細目で理解すべき範囲は、フォーム送信時の動的URL構築と、パス変数およびリクエストパラメータの設計上の使い分け基準まで。
|
|
キーワード
|
① URLパス変数 ② @PathVariable ③ プレースホルダ ④ Thymeleafリンク式 ⑤ リソース識別子
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で学んだURLパス変数の仕組みについて、コントローラ側でのアノテーションの記述方法と、ビュー側でのThymeleafリンク式の構文を重点的に振り返ってください。特に、以前学んだリクエストパラメータ（?key=value形式）との実装上の違いや、使い分けの基準について整理しておくことが重要です。また、手元で簡単な一覧画面と詳細画面の遷移を作成し、IDがURLの一部として正しく渡されるか動作確認を行うことを推奨します。
◆次回授業の予習
次回の授業では、ユーザーが入力したデータの妥当性を検証する「バリデーション」について学びます。Webアプリケーションにおいて、不正なデータ（空文字や形式誤りなど）が登録されることを防ぐためのチェック機能は必須です。入力フォームにおける必須入力チェックや文字数制限など、どのような検証ルールが必要になるか、一般的なWebサイトの登録フォームなどを例に想像しておいてください。また、Javaにおけるチェック処理のイメージを持っておくと理解がスムーズです。
|
|
24
|
バリデーションの基礎と単項目チェック
|
科目の中での位置付け
|
本講義は全45回のうち第24回に位置し、第5部「データ検証とデータベース操作」の冒頭となる重要な回である。これまで学習してきたSpring MVCによる画面遷移とデータ受け渡しの知識を基盤とし、実用的なWebアプリケーションに不可欠な「入力データの妥当性検証（バリデーション）」の概念と実装手法を導入する。特に、不正なデータの侵入を防ぎ、システムの堅牢性を高めるための基礎的な単項目チェックの手法を確立する段階である。
|
|
|
コマ主題細目
|
① 入力チェックの概念と分類 ② FormクラスとBean Validation ③ バリデーション実行と結果ハンドリング
|
|
細目レベル
|
① 本細目では、Webアプリケーションにおける入力チェック（バリデーション）の定義とその必要性について、テキストの冒頭部分に基づき理論的な側面から解説する。まず、バリデーションとは、ユーザーが入力したデータがアプリケーションの要件を満たしているか、また処理可能な形式であるかを確認するプロセスであることを定義する。不適切なデータがシステム内部に混入することで引き起こされる予期せぬエラーや、セキュリティ上の脆弱性（SQLインジェクションやクロスサイトスクリプティングなど）を防ぐために、入力チェックがいかに重要であるかを学生に認識させる。その上で、バリデーションの種類を大きく二つに分類して解説する。一つ目は「単項目チェック」である。これは、入力された個々のフィールドに対して、必須入力であるか、指定された文字数以内か、数値や日付の形式が正しいかといった、その項目単体で完結する制約を確認するものである。二つ目は「相関項目チェック」である。これは、パスワードとその確認用入力の一致確認や、開始日が終了日より前であるかの確認など、複数の項目間の論理的な整合性を検証するものである。本講義では、まず基礎となる単項目チェックに焦点を当てることを明示する。また、バリデーションを行う場所として、クライアントサイド（ブラウザ上のJavaScript等）とサーバーサイド（Javaプログラム）が存在することを触れ、セキュリティの観点からサーバーサイドでのチェックが必須であることを強調する。クライアントサイドのチェックはユーザビリティの向上には寄与するが、悪意のあるユーザーによって回避可能であるため、最終防衛ラインとしてのサーバーサイドバリデーションの不可欠性を論理的に説明する。これらの概念整理を通じて、学生は単なる機能実装としてではなく、システム設計における品質保証の一環としてバリデーションを捉える視点を養う。この細目で理解すべき範囲は、バリデーションの定義、必要性、および単項目チェックと相関項目チェックの概念的相違まで。
|
② 本細目では、Spring Frameworkにおけるバリデーション実装の中核となる「Formクラス」と「Bean Validation」の仕組みについて詳説する。「Form-Backing Bean（フォームバッキングビーン）」の概念を導入し、画面からの入力データを受け取るための専用クラス（Formクラス）を作成する意義を解説する。データベースのテーブル構造を反映したEntityクラスを直接画面入力に使用せず、Formクラスを別途用意することで、画面固有の入力要件（例えば、確認用パスワードフィールドの存在など）に柔軟に対応でき、かつEntityへの不正な値の混入を防ぐ役割分担が可能になることを理解させる。次に、Javaの標準的なバリデーション仕様であるBean Validation（Jakarta Validation）と、Springが提供するアノテーションを用いた宣言的なチェック定義について解説する。具体的には、Formクラスのフィールドに対して`@NotBlank`（必須入力）、`@Size`（文字長制限）、`@Min`/`@Max`（数値範囲）、`@Pattern`（正規表現マッチング）などのアノテーションを付与することで、チェックロジックをJavaコードとして記述することなく、メタデータとして定義できる利点を説明する。これにより、コードの可読性が向上し、ボイラープレートコード（定型的なチェック処理）が削減されることを示す。また、これらのアノテーションがどのように解釈され、検証ルールとして適用されるかの内部メカニズムについても概観する。さらに、各アノテーションにはエラーメッセージを指定する属性が存在し、デフォルトのメッセージではなく、ユーザーフレンドリーな任意のメッセージを設定する方法についても触れる。学生には、Formクラスの設計と適切なアノテーションの選択が、堅牢な入力チェック実装の第一歩であることを認識させ、実際のコード記述に向けた準備を整えさせる。この細目で理解すべき範囲は、Form-Backing Beanの役割、および主要なバリデーションアノテーションの種類と使用方法まで。
|
③ 本細目では、Controller層におけるバリデーションの実行トリガーと、検証結果のハンドリング、およびView層（Thymeleaf）でのエラー表示方法について実践的な解説を行う。まず、Controllerのメソッド引数として受け取るFormクラスに対して、`@Validated`（または`@Valid`）アノテーションを付与することで、Spring MVCがリクエストパラメータをバインドする際に自動的にバリデーションを実行する仕組みを詳説する。ここで極めて重要な概念として、`BindingResult`インターフェースを導入する。`BindingResult`は検証結果（エラーの有無や内容）を保持するオブジェクトであり、必ず検証対象のFormクラスの直後の引数として定義しなければならないというSpring MVCの制約を強調する。この順序を誤ると、検証エラー発生時に即座に例外がスローされ、適切なエラーハンドリングができなくなるためである。次に、`BindingResult`の`hasErrors()`メソッドを用いた条件分岐により、エラーが存在する場合の処理フローを解説する。通常、エラーがある場合は処理を中断し、入力画面（View）へフォワードしてユーザーに再入力を促す実装パターンを示す。その際、FormオブジェクトとBindingResultの内容は自動的にModelに格納され、Viewへ引き継がれる仕組みを理解させる。最後に、Thymeleaf側でのエラー表示方法として、`th:errors`属性を用いたフィールドごとのエラーメッセージ表示や、`th:classappend`を用いたエラー発生項目のスタイル変更（背景色を赤くするなど）の手法を解説する。これにより、ユーザーに対して具体的にどの項目でどのような誤りがあったかを視覚的にフィードバックするUI/UXの重要性を説く。また、`@ModelAttribute`を用いたFormの初期化や、入力画面表示時の空のFormインスタンスの受け渡しについても触れ、一連のリクエスト処理の中でFormオブジェクトがどのようにライフサイクルを持つかを統合的に理解させる。この細目で理解すべき範囲は、Controllerでのバリデーション実行、BindingResultによる判定、およびThymeleafでのエラー表示実装まで。
|
|
キーワード
|
① バリデーション ② 単項目チェック ③ Form-Backing Bean ④ アノテーション ⑤ BindingResult
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で扱ったバリデーションの仕組みについて、データがクライアントからサーバーへ送信され、Formクラスにバインドされ、アノテーションに基づいて検証が行われ、その結果がControllerで判定されて再びViewに表示されるまでの一連のデータフローを図に描いて整理すること。特に、BindingResultがどのタイミングで生成され、どのようにViewへ渡されるかの流れを重点的に再確認すること。
◆次回授業の予習
次回は単項目チェックでは対応できない、複数項目にまたがる「相関項目チェック」について学習する。例えば「パスワードと確認用パスワードが一致しているか」といったロジックを検証する場合、今回学んだ単一フィールドへのアノテーション付与だけでは実現できない理由を思考し、どのようにして複数のフィールド値を比較検証すればよいか、Javaのクラス構造の観点から仮説を立てておくこと。
|
|
25
|
バリデーションの応用
|
科目の中での位置付け
|
本講義は、全6回からなる第5部「データ検証とデータベース操作」の第2回目に位置します。前回学習した単項目チェック（Bean Validation）だけでは対応できない、複数の入力項目間の整合性を検証する「相関チェック」について扱います。業務アプリケーションでは必須となる高度な入力検証手法を習得し、不正なデータの登録を防ぐ堅牢なWebアプリケーションを構築するための基礎能力を養います。
|
|
|
コマ主題細目
|
① 相関項目チェックの概念と@AssertTrueによる実装 ② Validatorインターフェースによる独自バリデーションの実装 ③ バリデーションの実行順序とエラーハンドリング
|
|
細目レベル
|
① 本細目では、単項目チェックでは網羅できない入力値検証の課題と、その解決策の一つである`@AssertTrue`アノテーションを用いた実装手法について詳説する。まず、相関項目チェックの定義とその必要性について理論的に整理する。Webアプリケーションにおいて、入力データの妥当性検証は単一フィールドの制約確認だけでは不十分な場合が多い。例えば、「パスワード」と「確認用パスワード」の一致確認や、「開始日」と「終了日」の前後関係の整合性など、ある項目の正当性が他の項目の値に依存するケースがこれに該当する。このような複数のフィールド値を参照し、論理的な整合性を判定する検証を相関項目チェックと呼ぶ。
次に、Java Bean Validationの標準機能である`@AssertTrue`アノテーションを活用した実装方法を解説する。この手法は、データ保持用のクラス（Formクラス）内部にバリデーションロジックを直接記述するアプローチである。具体的には、Formクラス内に判定用のメソッドを定義し、その戻り値を`boolean`型とする。メソッド内部では、`this`キーワードを用いて自身の複数のフィールド値にアクセスし、比較演算などを用いて整合性を判定するロジックを記述する。例えば、二つのフィールドが一致していれば`true`を、不一致であれば`false`を返すように実装する。そして、このメソッドに対して`@AssertTrue`アノテーションを付与し、検証失敗時のメッセージを設定することで、Spring Frameworkのバリデーション機構が自動的にこのメソッドを実行し、結果を判定する仕組みとなっている。
この手法の利点は、高い凝集性と実装の容易さにある。バリデーションロジックがデータ構造定義であるFormクラス内に記述されるため、クラス定義を参照するだけでデータの制約条件を把握しやすい。また、新たなバリデータクラスを作成する必要がなく、アノテーションを付与するだけで機能するため、開発コストを低く抑えることができる。しかし一方で、Formクラスの役割が肥大化するという懸念もある。本来、Formクラスは画面からの入力値を保持するData Transfer Object（DTO）としての役割が主であるが、そこに複雑なロジックが混在することは、ソフトウェア設計における「関心の分離」という観点からは議論の余地があることを理解させる。
この細目で理解すべき範囲は、相関項目チェックの必要性を理解し、`@AssertTrue`アノテーションを用いてFormクラス内で複数項目の整合性検証を実装する方法とその特性まで。
|
② 前述のアノテーションベースの実装は手軽である反面、ロジックとデータ保持の混在や再利用性の低さといった課題を抱えている。より構造的かつ拡張性の高いバリデーションを実現するために、Spring Frameworkが提供する`Validator`インターフェースを実装する方法について詳説する。この手法は、バリデーションロジックをFormクラスから切り離し、独立したクラスとして定義するものである。これにより、複雑なビジネスルールに基づく検証や、他機能でのロジック再利用が容易になる。
まず、`Validator`インターフェースの構造について解説する。このインターフェースは主に二つのメソッド、`supports`と`validate`を定義している。`supports`メソッドは、そのバリデータが検証対象とするクラス（Formクラスなど）が適切かどうかを判定するために使用される。引数として渡されたクラスタイプが、想定しているクラスと一致するか、あるいはそのサブクラスであるかを確認し、`boolean`値を返すことで、型安全性を担保する役割を果たす。
次に、検証の中核となる`validate`メソッドの実装について詳説する。このメソッドは、実際の検証対象オブジェクトと、エラー情報を保持する`Errors`インターフェースを受け取る。開発者はこのメソッド内で、対象オブジェクトを適切な型にキャストし、各フィールドの値を取り出して比較・検証を行うロジックを記述する。検証の結果、不正と判断された場合は、`Errors`オブジェクト（実体としては`BindingResult`などが渡される）に対してエラーを登録する。エラー登録には`reject`や`rejectValue`メソッドを使用し、エラーコードやデフォルトメッセージを指定することで、後の画面表示処理へと連携させる。
さらに、作成した独自バリデータをControllerに適用する手順として、`@InitBinder`アノテーションの使用方法を解説する。Controllerクラス内に`WebDataBinder`を引数に取るメソッドを用意し、`@InitBinder`を付与することで、リクエスト処理の前にデータバインディングの設定を行うことができる。このメソッド内で`binder.addValidators`を呼び出し、作成したバリデータのインスタンスを登録することで、Spring MVCの処理フローの中で自動的に検証が実行されるようになる。この一連の流れを通じて、責務が分離された堅牢なバリデーション設計手法を習得させる。
この細目で理解すべき範囲は、Springの`Validator`インターフェースを実装した独自バリデータークラスの作成方法、`supports`および`validate`メソッドの役割、そしてControllerにおける`@InitBinder`を用いた登録手順まで。
|
③ Webアプリケーションにおける入力検証では、単項目チェックと相関項目チェックが併用されることが一般的である。これらの検証処理がどのような順序で実行され、エラーがどのように管理・表示されるかを理解することは、ユーザーフレンドリーなアプリケーションを構築する上で極めて重要である。本細目では、Spring Frameworkにおけるバリデーションの実行順序制御と、検証結果であるエラー情報の取り扱いについて詳説する。
まず、バリデーションの実行順序について解説する。Spring MVCのデータバインディングプロセスにおいて、通常、JSR-303/Bean Validationに基づくアノテーションによる単項目チェックが最初に実行される。これには`@NotNull`や`@Size`などの基本的制約が含まれる。その後、Controllerに登録されたSpring独自の`Validator`（相関チェックなど）が実行されるという順序が一般的である。この順序性は実務上重要な意味を持つ。なぜなら、単項目チェックで形式エラー（例えば、数値項目に文字列が入力された、あるいは必須項目が空であるなど）が検出された場合、後続の相関チェックを行う前提条件が崩れている可能性があるからである。例えば、数値であることを前提とした大小比較を行う相関チェックにおいて、片方の値がnullであればNullPointerExceptionが発生するリスクがある。したがって、単項目チェックでエラーが発生した場合には、後続の相関チェックを実行しないように制御する仕組みや、相関チェック側でも値の存在確認を行うといった防御的な実装の重要性を理解させる。
次に、エラーハンドリングと画面表示の仕組みについて詳説する。検証プロセスで検出されたエラーは、すべて`BindingResult`インターフェースに蓄積される。ここには、特定のフィールドに関連付いた「フィールドエラー」と、特定のフィールドに紐づかない「グローバルエラー」の二種類が存在する。単項目チェックのエラーは通常フィールドエラーとなり、相関チェックのエラーは、特定フィールドに関連付けることも、グローバルエラーとして登録することも可能である。Thymeleafを用いた画面表示においては、これらのエラー種別に応じた表示方法を使い分ける必要がある。フィールドエラーであれば入力フォームの該当項目の近傍に表示し、グローバルエラーであればフォームの上部などにまとめて表示することで、ユーザーに適切なフィードバックを提供する手法を学ぶ。
この細目で理解すべき範囲は、単項目チェックと相関チェックの実行順序の原則、`BindingResult`におけるエラー情報の構造、およびThymeleafを通じたユーザーへのエラーメッセージ表示の仕組みまで。
|
|
キーワード
|
① 相関項目チェック ② @AssertTrue ③ Validatorインターフェース ④ WebDataBinder ⑤ @InitBinder
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
単項目チェックと相関項目チェックの違いについて整理し、それぞれの実装方法（アノテーションベース、インターフェース実装ベース）の特徴やメリット・デメリットを比較してまとめておくこと。また、バリデーションエラーが発生した際に、Spring MVC内部でエラー情報がどのように保持され、View（画面）まで伝達されるかという一連のデータの流れを再確認しておくこと。
◆次回授業の予習
次回からデータベース操作の学習に入るため、Javaアプリケーションとデータベースを接続するための一般的な技術概念（JDBCなど）について確認しておくこと。また、オブジェクト指向言語のオブジェクトとリレーショナルデータベースのテーブルデータをどのように対応付けるかという「O/Rマッピング」の基本的な考え方について、用語の意味を調べておくこと。
|
|
26
|
O/RマッパーとMyBatisの概要
|
科目の中での位置付け
|
本講義は、第5部「データ検証とデータベース操作」の後半部分の導入回に位置する。これまでの講義では、ユーザーからの入力データの検証（バリデーション）について学習した。今回からは、検証済みのデータをデータベースに保存、あるいはデータベースから参照するための技術について学習を開始する。第1部で体験したJDBCによる煩雑なデータベース操作と比較し、現代的なフレームワークが提供するO/Rマッパーがいかに開発効率と保守性を高めるかを理解するための重要な転換点である。
|
|
|
コマ主題細目
|
① O/Rマッパーの概念と役割 ② MyBatisの特徴と仕組み ③ MyBatisの導入と構成要素
|
|
細目レベル
|
① Webアプリケーション開発において、データの永続化は中心的な課題の一つである。リレーショナルデータベース（RDB）はデータを表形式（テーブル）で管理し、正規化された構造を持つ一方で、Javaのようなオブジェクト指向プログラミング言語は、データと振る舞いをカプセル化したオブジェクトとしてデータを扱う。この両者の間には、データ構造やデータ型、関連の表現方法において根本的な相違が存在しており、これを「インピーダンスミスマッチ」と呼ぶことを解説する。第1部の講義で学生が体験したJDBCを用いた開発では、開発者はSQL文をJavaコード内に文字列として埋め込み、データベースから返却されたResultSet（結果セット）をwhileループなどで走査し、手動でJavaのオブジェクトに詰め替える作業を行っていた。この手法は、コードの可読性を著しく低下させるだけでなく、型変換のミスやリソースの解放漏れといったバグの温床となりやすいことを振り返りながら再確認させる。
こうした課題を解決するために登場した技術がO/Rマッパー（Object-Relational Mapper）であることを定義し、その基本的な役割について詳説する。O/Rマッパーは、リレーショナルデータベースのレコードとJavaのオブジェクト（インスタンス）の間のマッピングを自動化する仕組みであることを図解を用いて説明する。具体的には、データベースのテーブル名がクラス名に、カラム名がフィールド（メンバ変数）に対応し、SQLの実行結果が自動的にオブジェクトのリストなどに変換されるプロセスを解説する。これにより、開発者はSQLの発行やデータ変換といった低レイヤの処理から解放され、ビジネスロジックの実装に集中できることを強調する。また、O/Rマッパーを導入することで、データベース操作に関するコードが抽象化され、アプリケーションの保守性や再利用性が向上するというソフトウェア工学的なメリットについても論じ、フレームワークを利用する意義を深く理解させる。
この細目で理解すべき範囲は、JavaとRDBの構造的な違い（インピーダンスミスマッチ）と、それを解決するO/Rマッパーの基本的な定義および導入のメリットまで。
|
② Javaの世界にはJPA（Java Persistence API）やHibernateなど、多種多様なO/Rマッパーが存在するが、本講義で採用する「MyBatis」はその中でも「SQLマッパー」としての特性を持つフレームワークであることを解説する。フルスタックのORMがSQLの生成までも完全に自動化し、データベースの存在を極力隠蔽しようとするのに対し、MyBatisは開発者が明示的にSQLを記述し、そのSQLの実行結果とJavaオブジェクトのマッピングに主眼を置いている点を対比させながら説明する。この特性により、データベースの固有機能を活用した高度なチューニングや、複雑な結合を含む検索クエリを柔軟に記述できるというMyティスの強みを理解させる。特に、既存のデータベース資産を活用する場合や、パフォーマンス要件が厳しくSQLの実行計画を細かく制御したい場合に、MyBatisが適していることを実践的な観点から解説する。
次に、MyBatisが動作する具体的な仕組みについて詳説する。MyBatisでは、Javaのメソッド呼び出しと実行すべきSQL文を紐づけるために、XML形式の設定ファイル（マッパーファイル）またはJavaのアノテーションを使用することを説明する。Javaプログラムから渡された引数（パラメータ）が、どのようにしてSQL文のプレースホルダ（?）にバインドされ、データベースで実行された結果がどのようにしてJavaのPOJO（Plain Old Java Object）にマッピングされて戻ってくるのか、その内部的なデータフローを順を追って解説する。この過程で、MyBatisが提供する機能がいかにJDBCのボイラープレートコード（定型的なコード）を削減しているかを示し、第1部で苦労して記述した処理がMyBatisによってどのように簡潔化されるかを具体的にイメージさせる。また、MyBatisはシンプルで学習コストが比較的低いとされており、初学者がSQLとJavaの連携を学ぶための教材としても優れている点に触れる。
この細目で理解すべき範囲は、他のORMと比較した際のMyBatisの特徴（SQLマッパーであること）と、パラメータのバインドから結果マッピングまでの基本的な動作原理まで。
|
③ Spring BootプロジェクトにおいてMyBatisを利用可能にするための導入手順と、アプリケーションを構成する主要な要素について解説する。まず、ビルドツールであるGradleを用いて、依存関係定義ファイル（build.gradle）に「mybatis-spring-boot-starter」を追加することで、必要なライブラリ群が一括してダウンロードされ、プロジェクトに組み込まれる流れを説明する。これはSpring Bootのスターター機能によるものであり、複雑な依存関係解決やバージョン管理が自動化されていることを再確認させる。また、データベースへの接続情報（JDBC URL、ユーザー名、パスワードなど）を「application.properties」に記述するだけで、Spring Bootが自動的にDataSourceを設定し、MyBatisが利用可能な状態になる仕組みについても解説する。
続いて、MyBatisを用いた開発における3つの主要な構成要素である「Entityクラス」「Mapperインターフェース」「Mapper XMLファイル」の役割と関係性について詳説する。Entityクラスはデータベースのテーブル構造に対応したJavaクラスであり、データを保持する役割を持つことを説明する。Mapperインターフェースは、データベース操作を行うメソッド（CRUD操作など）を定義するJavaのインターフェースであり、SpringのDIコンテナによって管理されるコンポーネントとなることを解説する。ここで定義したメソッドと対になるSQL文を記述するのがMapper XMLファイルであり、インターフェースの完全修飾名とメソッド名をキーとして紐づけが行われる仕組みを理解させる。最後に、アーキテクチャ全体におけるMyBatisの位置づけとして、Service層（ビジネスロジック）からMapperインターフェースを@Autowiredによってインジェクションし、メソッドを呼び出すことでデータベースアクセスが実行される一連のフローを提示し、次回の実装演習への橋渡しとする。
この細目で理解すべき範囲は、Spring BootへのMyBatis導入手順、およびEntity、Mapperインターフェース、Mapper XMLのそれぞれの役割と相互関係まで。
|
|
キーワード
|
① O/Rマッパー ② MyBatis ③ SQLマッパー ④ Mapperインターフェース ⑤ インピーダンスミスマッチ
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の講義で学んだO/Rマッパーの概念と、これまでに学習したJDBCによるデータベース接続の違いを整理すること。特に、リレーショナルデータベースのテーブル構造とJavaのオブジェクト構造の間にあるギャップ（インピーダンスミスマッチ）が、O/Rマッパーによってどのように解消されるかを自身の言葉で説明できるように要点をまとめること。また、MyBatisが他のORMと比較してどのような特徴（SQLを直接記述する点など）を持っているかを確認すること。
◆次回授業の予習
次回は実際にMyBatisを用いてデータベースへのCRUD操作（作成、読み取り、更新、削除）を行うため、基本的なSQL構文について再確認しておくこと。特に、SELECT文を用いたデータの抽出条件の記述方法や、INSERT文によるデータの挿入方法など、リレーショナルデータベース操作の基礎的な文法を振り返っておくことが望ましい。また、Javaのインターフェースと実装クラスの関係についても、DIの観点から軽く復習しておくと次回の理解がスムーズになる。
|
|
27
|
MyBatisによるCRUD操作①（設定と参照）
|
科目の中での位置付け
|
本講義は、全45回にわたるWebアプリケーション開発演習の中盤に位置し、第5部「データ検証とデータベース操作」の核心部分にあたります。前回の講義で学習したO/Rマッパーの概念的理解に基づき、本講義では実際にSpring BootプロジェクトにおいてMyBatisを導入し、データベース接続から基本的なデータ参照処理を実装するまでの具体的な手順を習得します。これは、後の第6部で開発するToDoアプリにおけるデータ永続化処理の基礎となる極めて重要な回です。
|
|
|
コマ主題細目
|
① MyBatis導入のためのプロジェクト構築とデータベース接続設定 ② オブジェクト関係マッピングにおけるエンティティクラスの実装 ③ MapperインターフェースとXMLマッパーファイルによるデータ参照の実装
|
|
細目レベル
|
① 本細目では、Spring Frameworkを用いたWebアプリケーション開発において、MyBatisを利用するための環境構築および初期設定の手順について詳説します。まず、開発環境であるEclipse（Pleiades All in One）を使用し、Springスターター・プロジェクトの作成機能を通じて、新規プロジェクトを立ち上げます。この際、最も重要となるのが依存関係（Dependencies）の適切な設定です。これまでの講義で使用してきた「Spring Web」や「Thymeleaf」、「Lombok」といった基本的なライブラリに加え、データベース操作に不可欠な「MyBatis Framework」および「PostgreSQL Driver」を選択し、プロジェクトに追加する必要があります。これらのライブラリは、アプリケーションがデータベースと通信し、SQLを実行するための基盤を提供します。特にPostgreSQL Driverは、JavaアプリケーションがPostgreSQLデータベースに接続するためのJDBCドライバであり、MyBatis Frameworkは、JavaオブジェクトとSQLの間のマッピングを自動化するO/Rマッパーの本体です。
次に、アプリケーション全体の設定を司る「application.properties」ファイルの編集を行います。Spring Bootでは、このプロパティファイルにデータベースの接続情報を記述することで、起動時に自動的にデータソース（DataSource）が構成され、データベースへの接続が確立される仕組みとなっています。具体的には、接続先のデータベースURL（spring.datasource.url）、接続に使用するユーザー名（spring.datasource.username）、およびパスワード（spring.datasource.password）を正確に記述します。また、使用するJDBCドライバのクラス名（spring.datasource.driver-class-name）も指定し、PostgreSQLへの接続であることを明示します。これらの設定値は、環境構築時にインストールしたPostgreSQLの設定と完全に一致している必要があり、不一致がある場合はアプリケーション起動時に接続エラーが発生するため、細心の注意を払って記述することが求められます。本細目を通じ、学生はライブラリの依存管理からデータベース接続設定に至るまでの、データアクセス層構築の初動プロセスを実践的に理解します。この細目で理解すべき範囲は、MyBatisおよびPostgreSQLドライバを含むプロジェクトの作成から、application.propertiesへの接続情報記述によるDB接続準備の完了まで。
|
② 本細目では、リレーショナルデータベースのテーブル構造をJavaのオブジェクト指向プログラム内で扱うための「エンティティ（Entity）」クラスの設計と実装について解説します。O/Rマッパー（Object-Relational Mapper）の主な役割の一つは、データベースのレコードをJavaのオブジェクトにマッピング（対応付け）することです。このマッピングの受け皿となるのがエンティティクラスであり、一般的にデータベースの1つのテーブルが1つのエンティティクラスに対応し、テーブルのカラム（列）がクラスのフィールド（属性）に対応する構造をとります。
授業ではまず、PostgreSQL上にデータの取得対象となるテーブルを作成し、サンプルデータを投入する準備を行います。今回は例として、ユーザー情報を管理するテーブルを想定し、ID、名前、住所などのカラムを持つテーブルを定義します。その後、このテーブル構造に対応するJavaクラス「User」を作成します。クラスの作成にあたっては、Spring Bootのプロジェクト構成におけるパッケージングの作法に従い、`com.example.demo.entity`といった専用のパッケージに配置することで、クラスの役割を明確化します。
エンティティクラスの実装においては、各フィールドのデータ型をデータベースのカラムの型と適切に対応させる必要があります。例えば、データベースの数値型はJavaのInteger型、文字列型はString型に対応させます。さらに、これまでの講義で学習したライブラリ「Lombok」を積極的に活用します。クラスに対して`@Data`アノテーションを付与することで、各フィールドに対するゲッター（getter）、セッター（setter）、および`toString`メソッドなどを自動生成させます。これにより、冗長なボイラープレートコード（定型コード）の記述を省略し、クラスの可読性と保守性を高めることができます。学生は、テーブル定義書（または実際のテーブル構造）からJavaのクラス定義を導き出すプロセスを通じて、データモデルとオブジェクトモデルの対応関係を深く理解するとともに、データを運ぶオブジェクト（DTO: Data Transfer Objectとしての側面も持つエンティティ）の役割を認識します。この細目で理解すべき範囲は、データベース上のテーブル作成から、それに対応するJavaのエンティティクラスの作成およびLombokによるメソッド自動生成まで。
|
③ 本細目では、MyBatisにおけるデータアクセス処理の中核を担う「Mapperインターフェース」と「XMLマッパーファイル」の実装方法について詳説します。MyBatisの特徴は、SQL文をJavaコードから分離し、XMLファイル（またはアノテーション）に記述することで、SQLの管理を容易にする点にあります。授業では、この分離構造を実現するための具体的な手順を実践します。
まず、データアクセス層のインターフェースとして、`com.example.demo.repository`パッケージに`UserMapper`インターフェースを作成します。このインターフェースには、MyBatisのコンポーネントであることを示す`@Mapper`アノテーションを付与します。そして、データベースから全件検索を行うための抽象メソッド（例：`selectAll`）を定義します。この時点ではメソッドの実装（中身）は記述しません。実装はMyBatisが実行時に動的に生成するためです。
次に、実際のSQL文を記述するためのXMLマッパーファイル（`UserMapper.xml`）を作成します。このファイルの配置場所は重要であり、`src/main/resources`配下に、Javaのパッケージ階層と同じフォルダ構成（`com/example/demo/repository`）を作成して配置する必要があります。XMLファイル内では、``タグの`namespace`属性に、先ほど作成したMapperインターフェースの完全修飾名（パッケージ名を含むクラス名）を指定します。これにより、インターフェースとXMLファイルが紐付けられます。
続いて、`
|
|
キーワード
|
① MyBatis ② O/Rマッパー ③ エンティティ ④ Mapperインターフェース ⑤ XMLマッパーファイル
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の講義で作成したSpring Bootプロジェクトの構成を再確認してください。特に、`build.gradle`に追加した依存関係の意味や、`application.properties`に記述したデータベース接続設定の各項目（URL、ユーザー名、パスワード、ドライバクラス名）がどのような役割を果たしているかを整理してください。また、Javaのエンティティクラスとデータベースのテーブル定義を見比べ、フィールド名とカラム名、データ型がどのように対応しているかを確認し、O/Rマッピングの基本的な仕組みを振り返っておくことが重要です。
◆次回授業の予習
次回の講義では、今回作成したデータアクセス層（Mapper）を利用して、取得したデータを画面（View）に表示する処理を実装します。そのため、Spring MVCにおけるControllerからView（Thymeleaf）へデータを渡すための`Model`インターフェースの使い方や、Thymeleafにおいてリストデータを繰り返し表示するための`th:each`属性の記述方法について、テキストを読み返して復習しておいてください。データの流れ（DB→Mapper→Service→Controller→View）をイメージできるようにしておくとスムーズに理解できます。
|
|
28
|
MyBatisによるCRUD操作②
|
科目の中での位置付け
|
本講義は、全45回構成の第28回にあたり、第5部「データ検証とデータベース操作」の中核を成す。前回までに構築したデータベース環境およびO/Rマッパー（MyBatis）の設定とデータアクセス層（Mapper）の実装を受け、今回はWebアプリケーション層（Controller）と表示層（View）を実装し、データベースから取得したデータをエンドユーザが視認できる画面として出力するまでの一連のプロセスを完結させる重要な位置づけにある。これにより、Webアプリ開発における基本的なデータ参照フロー（MVCモデルとDB連携）の全体像を把握させる。
|
|
|
コマ主題細目
|
① コントローラにおけるデータ取得処理の実装 ② Thymeleafを用いたリストデータの表示実装 ③ アプリケーションの統合動作確認と検証
|
|
細目レベル
|
① 本細目では、Spring MVCアーキテクチャにおけるコントローラ（Controller）の役割を再確認しつつ、前回作成したデータアクセス層（Mapper）と連携してデータベースからデータを取得する処理を実装する。まず、コントローラの責務について詳説する。コントローラは、クライアントからのHTTPリクエストを受け取り、適切なビジネスロジックやデータアクセス処理を呼び出し、その結果をビュー（View）に渡す役割を担う。本講義では、MyBatisのMapperインターフェースをコントローラ内で利用可能にするために、Dependency Injection（依存性の注入）のメカニズムを活用する。具体的には、コントローラクラスのフィールドとしてMapperインターフェースを宣言し、`@Autowired`アノテーションを付与することで、SpringのDIコンテナによって自動的に生成されたMapperの実装クラスのインスタンスが注入される仕組みを解説する。これにより、開発者はデータアクセスの詳細な実装を意識することなく、インターフェースのメソッドを呼び出すだけでデータベース操作が可能となることを理解させる。次に、ハンドラメソッドの実装について解説する。`@GetMapping`などのアノテーションを用いて特定のリクエストURLに対する処理メソッドを定義し、その内部でMapperのメソッド（例：`selectAll`など）を呼び出す。この際、戻り値として取得されるデータは、JavaのListコレクションなどに格納されたエンティティオブジェクトの集合となる。続いて、取得したデータをビューへ引き渡すための`Model`インターフェースの利用方法について詳説する。`Model`オブジェクトの`addAttribute`メソッドを使用し、取得したリストデータを任意の属性名で格納することで、ビュー側からそのデータを参照可能にする仕組みを具体的なコード例（概念的な説明に留める）とともに説明する。最後に、メソッドの戻り値として遷移先のビュー名（HTMLファイル名）を指定することで、処理フローが完結することを体系的に理解させる。この細目で理解すべき範囲は、コントローラクラスへのMapperのDI、データ取得メソッドの呼び出し、およびModelを介したビューへのデータ受け渡し処理の実装まで。
|
② 本細目では、コントローラから渡されたデータをユーザインターフェースとして表示するためのビュー（View）の実装について、テンプレートエンジンThymeleafを用いて詳説する。まず、Webアプリケーションにおける動的コンテンツ生成の仕組みについて解説する。サーバサイドレンダリングでは、静的なHTMLテンプレートに対し、サーバ側で処理されたデータを埋め込むことで、クライアントごとに異なる内容を持つHTMLを生成してレスポンスする。本講義では、特にデータベースから取得した「複数件のデータ（リスト）」を表形式などで一覧表示する手法に焦点を当てる。具体的には、Thymeleafが提供する繰り返し処理のための属性である`th:each`の構文と動作原理について詳細に解説する。`th:each`は、HTMLタグ（例えば`＜tr＞`タグ）に記述することで、指定されたコレクション（List）の要素数分だけそのタグを複製し、各要素のデータを順番に処理する機能を持つ。構文としては「要素変数 : ${コレクション変数}」の形式をとり、ループごとに現在の要素が要素変数に代入される仕組みを理解させる。次に、各要素（エンティティオブジェクト）のプロパティ値を表示するための`th:text`属性の利用方法を解説する。`th:text="${要素変数.フィールド名}"`のように記述することで、JavaのBean規約に基づき、自動的に対応するgetterメソッドが呼び出され、その戻り値がHTMLのテキストとして出力されるプロセスを詳説する。また、HTMLファイルを作成する際の基本的なルールとして、`＜html＞`タグへのThymeleaf名前空間（xmlns:th）の宣言が必要である点や、静的なプレビュー時にもレイアウトが崩れないようなHTMLコーディングの配慮についても触れる。これにより、学生はJavaのオブジェクトデータをHTMLドキュメント上の視覚的な情報へと変換する具体的な技術を習得する。この細目で理解すべき範囲は、Thymeleafを使用したHTMLテンプレートの作成、`th:each`によるリストデータの反復表示、およびオブジェクトプロパティの出力実装まで。
|
③ 本細目では、これまでに実装したデータベース（PostgreSQL）、データアクセス層（MyBatis Mapper）、アプリケーション層（Controller）、およびプレゼンテーション層（View）を統合し、一つのWebアプリケーションとして正常に動作することを確認・検証するプロセスを詳説する。まず、Spring Bootアプリケーションの起動メカニズムを振り返る。mainメソッドを含む起動クラスを実行することで、Spring Bootの自動設定機能が働き、内蔵Tomcatサーバが立ち上がり、コンポーネントスキャンによって各レイヤのBean（ControllerやMapperなど）がDIコンテナに登録される一連の流れを再確認する。次に、ブラウザを用いた実地検証の手順を解説する。指定されたURL（例：`http://localhost:8080/パス`）へリクエストを送信し、データベースに保存されているレコードが期待通りに画面上のテーブルなどに一覧表示されるかを確認する。この際、単に表示されるだけでなく、事前にpgAdmin等のデータベース管理ツールを用いて登録しておいたテストデータの内容と、画面上の表示内容が正確に一致しているか（データの整合性）を確認することの重要性を説く。さらに、想定通りの結果が得られなかった場合のトラブルシューティングの基礎についても言及する。例えば、画面が真っ白になる、エラーページが表示される、あるいはデータが表示されないといった事象に対して、コンソールのログ出力を確認し、例外情報のスタックトレースから原因（SQLの記述ミス、プロパティ名の不一致、テンプレートの配置場所ミスなど）を特定するアプローチ方法を概観する。また、MyBatis特有の観点として、Mapper XMLファイルとMapperインターフェースのメソッド名の不一致などが原因で起動時にエラーになるケースなど、典型的なミスについても触れ、デバッグ能力の向上を図る。この細目で理解すべき範囲は、アプリケーションの起動からブラウザでの表示確認、データの整合性検証、および基本的なトラブルシューティングの手法まで。
|
|
キーワード
|
① コントローラ ② xmlns: ③ Modelインターフェース ④ th:each ⑤ Listコレクション
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で実装した、ControllerからMapperを呼び出し、取得したリストデータをModelに格納してViewに渡す一連の流れを振り返る。特に、DI（依存性の注入）がどのように機能してMapperが利用可能になったか、そしてThymeleafの繰り返し処理がどのようにJavaのListオブジェクトをHTMLの表組みに変換したかについて、コードと画面の対応関係を確認しながら整理する。
◆次回授業の予習
次回はMyBatisの高度なマッピング機能であるResultMapについて学習する。データベースのテーブル定義におけるカラム名と、Javaクラスのフィールド名が異なる場合に、自動的なマッピングが行われない問題について想定しておく。また、テーブル結合など、より複雑なSQL結果をオブジェクトにマッピングする必要性について、一般的なリレーショナルデータベースの概念から考察しておく。
|
|
29
|
高度なマッピング（ResultMap）
|
科目の中での位置付け
|
本講義は、第5部「データ検証とデータベース操作」の最終回に位置し、MyBatisを用いたデータベース操作技術の総仕上げとなる。前回までに学習した基本的なCRUD操作に加え、実務開発で頻出する「データベース設計とオブジェクト設計の不一致」や「複数テーブルにまたがるデータ取得」といった複雑な要件に対応するための高度なマッピング技術（ResultMap）を習得する。これにより、次部から始まる実践的なアプリケーション開発（ToDoアプリ）において、複雑なデータ構造を自在に扱える能力を確立する。
|
|
|
コマ主題細目
|
① ResultMapの概念と基本構造 ② 複数テーブルの結合と関連データのマッピング ③ 複雑なデータ構造の取得と画面表示の実装
|
|
細目レベル
|
① 本細目では、MyBatisにおける最も強力かつ重要な機能の一つである`ResultMap`の概念とその基本的な定義方法について詳細に解説する。これまで学習した`resultType`を使用した自動マッピングは、データベースのカラム名とJavaのエンティティクラスのフィールド名が完全に一致している（あるいはキャメルケース変換などの規則に従っている）場合にのみ機能する簡易的な手法であった。しかし、実際のシステム開発、特に既存のデータベースを利用する場合や、命名規則が厳格に定められているプロジェクトにおいては、カラム名とフィールド名が一致しないケースが多々発生する。このような「インピーダンスミスマッチ」の一つである名称の不一致を解決するために、開発者が明示的にマッピングルールを定義する仕組みが`ResultMap`である。
授業ではまず、`ResultMap`が解決する具体的な課題とメリットを概観する。特に、SQLのクエリ結果（リザルトセット）をJavaオブジェクトに変換する際、どのカラムをどのプロパティに代入するかを細かく制御できる点に焦点を当てる。XMLマッパーファイルにおける`＜resultMap＞`タグの構文構造について詳説し、マッピングの一意性を識別するためのID属性と、マッピング先のJavaクラス型を指定するtype属性の役割を理解させる。
次に、`ResultMap`内部の構成要素である`＜id＞`タグと`＜result＞`タグの使い分けについて解説する。`＜id＞`タグはデータベースの主キー（Primary Key）に対応するカラムをマッピングするために使用され、MyBatisがオブジェクトの同一性を判断したり、キャッシュ機能を効率的に利用したりするための重要な情報となることを説明する。一方、`＜result＞`タグは主キー以外の一般カラムのマッピングに使用される。これらのタグを用いて、データベース上の「スネークケース（例：user_name）」のカラムを、Java上の「キャメルケース（例：userName）」のフィールドに手動で紐付ける具体的な記述方法を提示する。学生には、自動マッピングに頼らず明示的に定義することの堅牢性と、再利用性（一度定義したResultMapは複数のSELECT文で参照可能である点）について理解を深めさせる。この細目で理解すべき範囲は、ResultMapの必要性を理解し、XMLファイルにおいて基本的な`＜resultMap＞`タグ、`＜id＞`タグ、`＜result＞`タグを正しく定義できるところまで。
|
② 本細目では、リレーショナルデータベースの正規化された複数テーブルからデータを取得し、それをJavaのオブジェクト構造にマッピングする高度な手法について学習する。実務的なアプリケーションでは、単一のテーブルからデータを取得するだけでなく、関連する複数のテーブルを結合（JOIN）して情報を抽出することが一般的である。「テーブル構成」および「エンティティの追加と修正」で示される例に基づき、データベース上のリレーションシップ（関連）をJavaのオブジェクトモデルとしてどのように表現し、MyBatisを用いてどのように橋渡しするかを詳説する。
授業の進行としては、まず新しいテーブル構成の意図を理解させることから始める。例えば、あるエンティティが別のエンティティを参照するような構造（例：ユーザーが所属部署を持つ、あるいは商品がカテゴリを持つなど）を想定し、これに対応するためにJavaクラス側でフィールドを追加または修正するプロセスを解説する。ここでは、単にStringやint型のフィールドを追加するのではなく、別のクラスのインスタンスをフィールドとして保持する「コンポジション（包含）」の関係がJavaクラス上で表現されることを確認する。
続いて、「マッパーファイルの修正」に基づき、SQLのJOIN句を用いたSELECT文の作成と、その結果を受け取るためのResultMapの拡張について解説する。結合されたクエリ結果には、複数のテーブル由来のカラムが含まれることになるが、これらを適切に分解し、親オブジェクトと子オブジェクト（関連オブジェクト）の各フィールドに正しく値をセットするためのマッピング定義を学ぶ。ここでは、ResultMap内で関連するオブジェクトをマッピングするための記述方法や、ネストされたプロパティへのアクセス概念について触れ、複雑な階層構造を持つデータであっても、SQLの結果セットから一度のクエリで効率的にオブジェクトグラフを構築できるMyBatisの能力を理解させる。また、カラム名の衝突（異なるテーブルに同名のカラムが存在する場合など）を避けるためのSQLエイリアス（別名）の活用と、それに対応するResultMap側の記述の整合性についても注意を促す。この細目で理解すべき範囲は、JOINを含むSQL文を作成し、その結果をResultMapを用いて関連オブジェクトを含むJavaクラスにマッピングするXML定義の方法まで。
|
③ 本細目では、前段までに定義したResultMapとSQLを用いて実際にデータベースからデータを取得し、それをWebアプリケーションの画面（ビュー）に表示するまでの一連の実装プロセスを完遂させる。ここでは、データ層（MyBatis/DB）、ビジネスロジック層（Service）、プレゼンテーション層（Controller/View）がどのように連携し、複雑な構造を持つデータが受け渡されていくかを実践的に理解する。
まず、Mapperインターフェースにおけるメソッド定義と、XMLマッパーファイル内の`＜select＞`要素の記述をリンクさせる。`＜select＞`要素の`resultMap`属性において、先ほど定義したResultMapのIDを指定することで、クエリ実行結果が定義通りの複雑なオブジェクト構造として返却されるメカニズムを確認する。学生には、`resultType`属性を使用する場合との違いを明確に意識させ、単純な型指定では対応できないデータ構造が、ResultMapによってどのように解決されるかをコードレベルで認識させる。
次に、「ビューの修正」および「動作確認」に基づき、取得したデータをThymeleafテンプレートエンジンを用いてHTML画面に表示する方法を解説する。ResultMapによって構築されたオブジェクトは、Javaのクラス階層構造を持っているため、Thymeleaf側でもその階層を辿ってデータにアクセスする必要がある。例えば、親オブジェクトからドット記法を用いて子オブジェクトのプロパティを参照する方法（例：`${item.relatedObject.propertyName}`）や、リスト形式で取得された結合データを`th:each`でループ処理しながら表示する具体的な記述方法を実習する。
最後に、アプリケーション全体を起動し、ブラウザ上で正しく結合データが表示されるかを確認する。表示が正しくない場合やエラーが発生した場合のトラブルシューティングとして、ResultMapの定義ミス（カラム名の不一致、プロパティ名の誤り）やSQLのエイリアス設定漏れなどが主な原因となることを示し、ログに出力されるSQLやエラーメッセージから問題を特定するデバッグの視点も養う。これにより、MyBatisを用いた高度なデータ操作から画面表示までの一気通貫した開発スキルを定着させる。この細目で理解すべき範囲は、ResultMapを利用したデータ取得処理を実装し、Thymeleafを用いて階層化されたデータを適切に画面表示し、動作確認を行うまで。
|
|
キーワード
|
① ResultMap ② カラムマッピング ③ テーブル結合 ④ 関連エンティティ ⑤ XMLマッパーファイル
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
本日の講義で扱ったResultMapの定義方法について、XMLのタグ構造（id, resultなど）を見直して整理すること。特に、データベースのカラム名とJavaクラスのフィールド名が異なる場合に、どのようにマッピング定義を行えばよいか、具体的な記述例を思い出しながらノートにまとめること。また、テーブル結合（JOIN）を用いたSQLの結果が、Javaのオブジェクト構造（親クラスの中に子クラスが含まれる形）としてどのように変換されるのか、そのデータの流れとマッピングの仕組みを再確認し、理解を深めておくこと。
◆次回授業の予習
次回からはいよいよ第6部に入り、これまで学んだ知識を総動員して「ToDo管理アプリケーション」の作成を開始する。その第一歩として、アプリケーションの要件定義とデータベース構築を行うため、一般的なWebアプリケーション開発における設計工程の重要性について考えておくこと。また、これまでに学習したSpring Bootプロジェクトの作成手順や、データベース（PostgreSQL）へのテーブル作成用SQL（CREATE TABLE文など）の基本構文について軽く見直し、スムーズに開発に入力できるように準備しておくこと。
|
|
30
|
アプリケーション設計とデータベース構築
|
科目の中での位置付け
|
本講義は、全45回にわたるカリキュラムの第6部「実践アプリケーション開発」の第1回目にあたる。これまで第5部までに学習してきたSpring Frameworkのコア機能（DI、AOP）、Web表示技術（MVC、Thymeleaf）、およびデータアクセス技術（MyBatis）の知識を統合し、実際に動作する「ToDo管理アプリケーション」の開発に着手する重要な転換点である。本コマでは、開発の初動となる要件定義、プロジェクトの基盤構築、およびデータベースの準備を行い、以降の実装作業を円滑に進めるための土台を確立する。
|
|
|
コマ主題細目
|
① アプリケーション要件の定義とプロジェクトの作成 ② データベース環境の構築と接続設定の外部化 ③ レイヤ化アーキテクチャの適用と初期データの投入
|
|
細目レベル
|
① 本主題では、システム開発における最初の工程である「要件定義」の重要性を理解し、それを踏まえた上でSpring Bootプロジェクトの雛形を作成する手順を詳説する今回作成する「ToDo管理アプリケーション」が備えるべき機能要件を明確化する。具体的には、ユーザが自身のタスクを管理するために必要な「タスクの新規登録」「タスクの一覧表示」「タスクの詳細確認」「タスクの編集・更新」「タスクの削除」という、いわゆるCRUD（Create, Read, Update, Delete）機能を網羅することを定義する。学生には、単にコードを書くだけでなく、どのような課題を解決するためのシステムであるかを意識させ、エンジニアとして「何を作るか」を定義するプロセスの重要性を認識させる。
次に、定義された要件を実現するための開発プロジェクトを作成する。統合開発環境（IDE）上でSpring Starter Projectウィザード（Spring Initializr）を使用し、プロジェクトのメタデータ（グループ名、アーティファクト名など）を適切に設定する。ここで特に重要なのが、アプリケーションの構成要素となるライブラリ（依存関係）の選択である。本演習では、Webアプリケーションの基盤として「Spring Web」、画面生成を行うテンプレートエンジンとして「Thymeleaf」、データベース操作を行うO/Rマッパーとして「MyBatis Framework」、データベース接続用の「PostgreSQL Driver」、そしてJavaのボイラープレートコードを削減するための「Lombok」を選択する。また、入力値検証のために「Validation」も視野に入れる必要がある。
授業では、選択した各ライブラリがアプリケーションアーキテクチャの中でどのような役割を担うかを、これまでの講義内容と関連付けて詳細に解説する。例えば、Spring WebはMVCパターンのコントローラと通信制御を提供し、Thymeleafはビュー層を、MyBatisはモデル層の一部を担当することを再確認する。さらに、ビルドツールであるGradleがこれらの依存関係をどのように管理し、インターネット上のリポジトリから自動的にライブラリをダウンロードしてクラスパスに追加するのか、その仕組みについても概観する。最後に、生成されたプロジェクトのディレクトリ構造を確認し、Javaソースコードを格納する`src/main/java`と、設定ファイルや静的リソースを格納する`src/main/resources`の役割分担について理解を深める。これにより、モダンなWebアプリケーション開発における標準的なプロジェクト構成の基礎を固める。この細目で理解すべき範囲は、アプリケーションの機能要件の定義から、適切な依存関係を含んだSpring Bootプロジェクトの雛形作成まで。
|
② 本主題では、アプリケーションが扱うデータを永続的に保存するためのデータベース環境を構築し、Spring Bootアプリケーションから接続するための設定を行う手順について詳説する。Webアプリケーションにおいてデータストアは不可欠な要素であり、その構築と接続は開発の初期段階で確実に行っておくべき作業である。
まず、リレーショナルデータベース管理システム（RDBMS）を使用して、本アプリケーション専用のデータベースを作成する。手順に従い、DBを管理するGUIツール、あるいはコマンドラインツールを用いて、新規データベース「todo_db」を作成するプロセスを実践する。この際、データベースのエンコーディング（文字コード）やオーナー設定など、適切な環境構築に必要なパラメータについても解説し、文字化けや権限エラーなどの初歩的なトラブルを防ぐための知識を授ける。データベースというインフラストラクチャが正しく用意されて初めて、アプリケーションはデータの保存・利用が可能となることを強調する。
続いて、作成したデータベースに対してSpring Bootアプリケーションが接続できるようにするための設定を行う。これには、プロジェクト内の`src/main/resources`ディレクトリに配置されている`application.properties`ファイルを編集する。このファイルは、Spring Bootの動作を制御する様々な設定値を記述する場所であり、「設定の外部化（Externalized Configuration）」という重要な概念を体現している。授業では、データベース接続に必要な4つの主要なプロパティ、すなわち「JDBC URL」「ユーザ名」「パスワード」「ドライバクラス名」について詳細に解説する。特にJDBC URLの記述形式（`jdbc:postgresql://ホスト名:ポート番号/データベース名`）については、各部分がネットワーク上のどのリソースを指し示しているかを分解して説明し、TCP/IPネットワークを経由してデータベースにアクセスする仕組みを理解させる。
また、ソースコード内に接続情報をハードコーディングするのではなく、設定ファイルに分離することの意義についても深く掘り下げる。これにより、開発環境、テスト環境、本番環境といった環境ごとの設定値の差異を、ソースコードを変更することなく吸収できる利点を理解させる。さらに、設定ミスがアプリケーション起動失敗の主要な原因となるため、プロパティ名のタイプミスや不要な空白の混入などに注意を払い、正確に記述する能力を養う。あわせて、Spring Bootが起動時にこのファイルを読み込み、自動的にデータソース（DataSource）オブジェクトを生成してDIコンテナに登録する裏側の仕組みについても触れ、フレームワークの恩恵を認識させる。この細目で理解すべき範囲は、PostgreSQLでのデータベース作成から、application.propertiesを用いたデータベース接続設定の完了まで。
|
③ 本主題では、構築したプロジェクトに対して、保守性と拡張性を担保するための「レイヤ化アーキテクチャ」を適用し、データベースのテーブル作成と初期データの投入を行って、アプリケーションの起動確認を行うまでの一連の流れを詳説する。
まず、アプリケーションの内部構造を整理するために、Javaのパッケージ構成を作成する。ルートパッケージ配下に、役割に応じたサブパッケージを作成する。具体的には、HTTPリクエストを受け付け画面制御を担う`controller`、業務ロジックやトランザクション管理を担う`service`、データベースへのアクセスを抽象化する`repository`、そしてデータそのものを表現するドメインオブジェクトを格納する`entity`といった構成である。この作業を通じて、第1部から学んできた「関心の分離（Separation of Concerns）」というソフトウェア設計の原則を、実際のプロジェクト構成としてどのように具現化するかを実践的に学ばせる。各クラスを適切なパッケージに配置することは、コードの可読性を高め、チーム開発における混乱を防ぐために不可欠であることを強調する。
次に、データベース内にテーブルを作成し、テスト用のデータを投入する手順を行う。通常、SQLを手動で実行してテーブルを作成することも可能だが、Spring Bootにはアプリケーション起動時に特定のSQLスクリプトを自動実行する機能が備わっている。本講義ではこの機能を活用し、`src/main/resources`直下にテーブル定義（DDL）を記述した`schema.sql`と、初期データ（DML）を記述した`data.sql`を配置する方法を指導する。定義に従ってToDo情報を格納するテーブルのCREATE文を作成し、サンプルデータをINSERTするSQL文を記述する。これにより、開発環境の構築をコードベースで管理し、いつでもクリーンな状態から開発を開始できる「Infrastructure as Code」の初歩的な概念を体験させる。
最後に、これまでの設定がすべて正しく統合されているかを確認するために、Spring Bootアプリケーションを起動する。コンソールに出力されるログを読み解く方法を解説し、Tomcatが指定ポートで起動したこと、データベースへの接続が確立されたこと、そしてSQLスクリプトが正常に実行されたことを検証する。さらに、データベース管理ツールを用いて実際にテーブルが作成され、データが格納されていることを視覚的に確認させる。これにより、アプリケーション層とデータベース層の連携が成功したという確信を持たせ、次回以降の本格的なコード実装に向けた準備を完了させる。この細目で理解すべき範囲は、レイヤ化に基づくパッケージ構成の作成から、自動スクリプトによるテーブル構築および初期データの確認まで。
|
|
キーワード
|
① 要件定義 ② Spring Initializr ③ application.properties ④ レイヤ化アーキテクチャ ⑤ schema.sql
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業では、アプリケーション開発の起点となるプロジェクト作成と環境構築を行った。復習として、作成したSpring Bootプロジェクトのディレクトリ構造を再確認し、どのファイルがどこに配置されているかを把握すること。特に、`build.gradle`に記述された依存関係がそれぞれどのような役割（Web機能、DB操作、画面生成など）を持っているか整理すること。また、`application.properties`に記述したデータベース接続情報が、実際のデータベース設定とどのように対応しているかを確認し、設定ファイルによる外部化のメリットについて考察すること。
◆次回授業の予習
次回は、作成したプロジェクトに具体的なJavaクラスを追加していく。予習として、データベースのテーブル定義（カラム名やデータ型）と、それに対応するJavaのクラス（Entity）の関係性について整理しておくこと。また、MyBatisにおけるMapperインターフェースとXMLファイルの関係について、これまでの講義資料を振り返り、データアクセス層の実装イメージを持っておくこと。さらに、レイヤ化アーキテクチャにおける「Repository」と「Service」の役割の違いについて、テキストの該当箇所を読み、それぞれの責務を理解しておくこと。
|
|
31
|
アーキテクチャ構築とドメイン層の実装
|
科目の中での位置付け
|
本講義は、全9回にわたる「第6部：実践アプリケーション開発」の第2回目に位置し、前回定義した要件とデータベースに基づき、実際のJavaコーディングを開始する重要な段階である。ここでは、Spring Frameworkを用いた開発の骨格となる「レイヤ化アーキテクチャ」をプロジェクト内に構築し、アプリケーションの中核となるデータ構造（ドメインオブジェクト）を実装することで、以降のデータベース操作やビジネスロジック実装の基盤を確立する。
|
|
|
コマ主題細目
|
① レイヤ化アーキテクチャとパッケージ構成の確立 ② ドメインオブジェクト（Entity）の概念とデータ設計 ③ Lombokを活用したEntityクラスの実装と効率化
|
|
細目レベル
|
① 本講義の最初の主題として、Webアプリケーション開発における「レイヤ化アーキテクチャ」の概念を再確認し、それを実際のプロジェクト構成として具現化する作業を行う。まず、なぜアプリケーションを複数の層（レイヤ）に分割する必要があるのか、その理論的背景について解説する。「ドメイン駆動設計（DDD）」の用語を引用しつつ、アプリケーションを「ユーザーとの対話を行うアプリケーション層」、「ビジネスルールを処理するドメイン層」、「データの保存や外部通信を担当するインフラストラクチャ層」の3つに分類する考え方を整理する。この分類は、プログラムの「責務」を明確に分離し、コードの可読性、保守性、再利用性を高めるために不可欠な設計思想である。
具体的には、Spring Bootプロジェクトのsrc/main/javaディレクトリ配下に、各レイヤに対応するパッケージを作成する手順を実践する。Web層を担当する「controller」、ビジネスロジックを担当する「service」、データアクセスを担当する「repository」、そしてデータそのものを表現する「entity」という4つのパッケージを作成する。学生には、単にフォルダを作成する作業としてではなく、それぞれのパッケージがアプリケーション全体の中でどのような役割を担うかを意識させる。例えば、「controller」パッケージはHTTPリクエストを受け取る窓口であり、「repository」パッケージはデータベースという倉庫の管理を行う場所であるといった比喩を用いながら、各コンポーネントの配置場所を論理的に決定する能力を養う。
また、このパッケージ構成がSpring Frameworkの「コンポーネントスキャン」の仕組みと密接に関連していることも解説する。Spring Bootは起動時にこれらのパッケージを走査し、@Controller、@Service、@Repositoryといったアノテーションが付与されたクラスを自動的に検出してBeanとして登録する。したがって、適切なパッケージ構成を行うことは、フレームワークの機能を正しく動作させるための前提条件でもあることを理解させる。このように、本細目ではアーキテクチャの理論とSpring Bootにおける実装の慣習を結び付け、堅牢なアプリケーション構造の土台を築くことを目的とする。
この細目で理解すべき範囲は、Webアプリケーションにおけるレイヤ化の目的と各レイヤの役割、およびSpring Bootプロジェクトにおける具体的なパッケージ構成の手順まで。
|
② 次の主題として、アプリケーションが扱うデータをプログラム上で表現するための「ドメインオブジェクト（Entity）」について詳説する。Entityとは、現実世界の事象や概念をソフトウェア内のオブジェクトとしてモデル化したものであり、本演習における「ToDoアプリ」では、管理対象となる「タスク」そのものを指す。ここでは、前回データベースに作成したテーブル構造と、Javaプログラム上のクラス構造をどのようにマッピングするかという、O/Rマッピング（Object-Relational Mapping）の基礎概念について、実際の設計作業を通じて学習する。
具体的には、データベース上の「todo_items」テーブルと対になるJavaクラス「ToDo」の設計を行う。テーブルのカラムとして定義された「id（主キー）」、「title（件名）」、「detail（詳細）」、「importance（重要度）」、「deadline（期限）」、「done（完了フラグ）」といった各項目が、Javaクラスのフィールドとしてどのように表現されるかを検討する。例えば、データベースのVARCHAR型はJavaのString型に、INTEGER型はInteger型に、DATE型はDate型（またはLocalDate型）に対応するといった型変換のルールを確認する。特に、プリミティブ型（intなど）ではなくラッパークラス（Integerなど）を使用することで、データベースにおけるNULL値をJava上で適切に扱えるようにする点など、実務的なデータ設計の勘所についても触れる。
また、Entityクラスの役割が、単なるデータの入れ物（Data Holder）にとどまらず、アプリケーション内の各レイヤ間（RepositoryからService、ServiceからControllerへ）でデータを受け渡すための共通言語としての機能を持つことを説明する。「Domain Object」という用語を用い、このクラスがドメイン層に属する重要な構成要素であることを再確認する。学生には、Entityの設計が不適切であれば、後のデータベース操作や画面表示の実装において多大な手戻りが発生することを認識させ、テーブル定義書と照らし合わせながら正確にフィールドを定義することの重要性を理解させる。このプロセスを通じて、リレーショナルデータベースのレコードをオブジェクト指向言語のインスタンスとして扱うための抽象化能力を涵養する。
この細目で理解すべき範囲は、ドメインオブジェクト（Entity）の定義と役割、およびリレーショナルデータベースのテーブル構造とJavaクラスのフィールドとのマッピング関係の概念設計まで。
|
③ 最後の主題として、設計したEntityを実際にJavaクラスとして実装し、その過程でライブラリ「Lombok」を活用した効率的なコーディング手法を習得する。Javaにおいてデータを保持するクラス（Java Beans）を作成する場合、慣習的にすべてのフィールドをprivateで宣言し（カプセル化）、それらにアクセスするためのpublicなGetter/Setterメソッド、さらにはtoString、equals、hashCodeといったメソッドを実装する必要がある。しかし、これらのコードは定型的であり、フィールドの数に比例して記述量が増大するため、可読性の低下や修正時の手間（ボイラープレートコードの問題）を引き起こす要因となる。
本授業では、Lombokのアノテーションを使用することでこれらの問題を解決する方法を実践する。具体的には、作成したEntityクラスに対し、クラスレベルで「@Data」アノテーションを付与することで、Getter/SetterやtoStringメソッドなどがコンパイル時に自動生成される仕組みを確認する。また、フレームワーク（MyBatisなど）がインスタンスを生成するために必要なデフォルトコンストラクタを生成する「@NoArgsConstructor」と、全フィールドを初期化するコンストラクタを生成する「@AllArgsConstructor」も併せて適用する。これにより、数十行に及ぶはずのコードが数行のアノテーション記述だけで完結することを体験させる。
実装作業においては、IDE（Eclipse）の機能を活用し、Lombokによって裏側でメソッドが生成されていることを「アウトライン」ビューなどで確認させる。これにより、ソースコード上には記述がなくても、コンパイル後のクラスファイルにはメソッドが存在するというLombokの動作原理を直感的に理解させる。さらに、カプセル化の原則を守りつつ、開発効率を最大化する現代的なJava開発のスタイルを定着させる。学生には、単にアノテーションを貼ればよいという表面的な理解ではなく、それによって生成されるメソッドがなぜ必要なのか（例：フレームワークがリフレクションでプロパティにアクセスするためにGetter/Setterが必要、など）という背景知識も含めて指導する。最終的に、作成したEntityクラスがコンパイルエラーなくビルドできることを確認し、次回のデータベース操作実装への準備を完了する。
この細目で理解すべき範囲は、Lombokを活用したEntityクラスの実装手順と、アノテーションによって自動生成されるメソッド群の役割、およびJava Beanとしての要件を満たすクラス構造まで。
|
|
キーワード
|
① レイヤ化アーキテクチャ ② ドメインオブジェクト（Entity） ③ パッケージ構成 ④ 責務の分離 ⑤ Lombok
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で構築したパッケージ構成（Controller, Service, Repository, Entity）について、それぞれのパッケージにはどのような役割を持つクラスが配置されるべきか、自分の言葉で説明できるように整理してください。また、作成したEntityクラスの各フィールドが、データベースのテーブル定義のどのカラムと対応しているかを再確認し、Lombokのアノテーション（@Dataなど）が具体的にどのようなメソッドを自動生成しているかについても振り返っておいてください。
◆次回授業の予習
次回は、今回作成したEntityを用いて実際にデータベースへアクセスする処理を実装します。データベース操作の基本となるCRUD（Create, Read, Update, Delete）の概念について確認しておいてください。また、JavaのインターフェースとSQL（SELECT, INSERT文など）の基本的な構文について見直しておくと、MyBatisを用いたRepositoryの実装とMapper XMLの記述がスムーズに理解できます。特に、SQLにおけるパラメータの扱いや結果の取得方法について意識しておいてください。
|
|
32
|
データベース層の実装（RepositoryとMapper）
|
科目の中での位置付け
|
本講義は、全45回のうち第32回に位置し、第6部「実践アプリケーション開発」の中核を成す重要な回です。前回までに構築したドメイン層（Entity）と次回以降に実装するビジネスロジック層（Service）を繋ぐ「データベース層（Repository）」の実装を行います。Webアプリケーションにおけるデータ永続化の具体的な手段として、O/RマッパーであるMyBatisを用いたRepositoryインターフェースとMapper XMLの連携方法を習得し、Javaオブジェクトとリレーショナルデータベース間のデータ操作基盤を確立することを目的とします。
|
|
|
コマ主題細目
|
① MyBatisにおけるRepositoryインターフェースの役割と定義 ② アプリケーション要件に基づくCRUD操作とSQLの設計 ③ Mapper XMLファイルを用いたSQLのマッピング実装
|
|
細目レベル
|
① 本細目では、Spring FrameworkおよびMyBatisを用いたWebアプリケーション開発におけるデータアクセス層の実装方法として、Repositoryインターフェースの役割と具体的な定義手法について詳説します。まず、レイヤ化アーキテクチャにおけるRepositoryの責務について解説します。Repositoryは、ドメイン層やアプリケーション層からのデータアクセス要求を受け付け、データベースなどの永続化機構とのやり取りを隠蔽・抽象化する役割を担います。これにより、ビジネスロジックが具体的なデータアクセス技術（SQLやJDBCの詳細）に依存することを防ぎ、疎結合な設計を実現します。次に、MyBatis特有の実装形態である「Mapperインターフェース」について解説します。MyBatisでは、JavaのインターフェースとしてRepositoryを定義し、それに`@Mapper`アノテーションを付与することで、フレームワークが実行時に自動的に実装クラスを生成する仕組みを提供しています。この仕組みにより、開発者は煩雑なJDBCコードを記述することなく、メソッドの宣言のみでデータベース操作が可能となります。授業では、ToDoアプリケーションに必要な機能を網羅するメソッドのシグネチャ（メソッド名、引数、戻り値）の設計を行います。具体的には、全件取得を行う`findAll`、主キーによる1件検索を行う`findById`、新規登録を行う`insert`、更新を行う`update`、削除を行う`deleteById`といったメソッドを定義します。それぞれのメソッドにおいて、引数として渡すべきデータ型（Entityクラスやプリミティブ型）や、戻り値として期待される型（List、Entity、voidなど）を適切に選択する根拠を、Javaの型システムとデータ操作の観点から説明します。また、これらのメソッドが後述するXMLファイル内のSQL定義とどのように紐づけられるか、その命名規則やマッピングの仕組みについても触れ、インターフェース定義が単なる宣言ではなく、データアクセス処理の入り口として機能することを強調します。この細目で理解すべき範囲は、Repositoryパターンの概念からMyBatisにおけるMapperインターフェースの定義方法、およびCRUD操作に必要なメソッド設計まで。
|
② 本細目では、ToDoアプリケーションの機能要件を満たすために必要なデータベース操作を分析し、それらを実現するための具体的なSQL（Structured Query Language）文の設計と記述について詳説します。まず、Webアプリケーションにおける基本的なデータ操作モデルであるCRUD（Create, Read, Update, Delete）の概念を再確認し、本演習で作成するToDoアプリにおける具体的なユースケースと照らし合わせます。作成（Create）に関しては、新規ToDo項目をデータベースに保存するためのINSERT文を検討します。ここでは、自動採番される主キー以外のカラム（タイトル、詳細、期限など）に対して値を設定する構文を確認します。読取（Read）に関しては、登録されたToDoの一覧を表示するための全件検索を行うSELECT文と、編集画面などで特定のToDo情報を取得するための主キー検索を行うSELECT文の2種類を設計します。更新（Update）に関しては、既存のToDo項目の内容を変更したり、完了状態を切り替えたりするためのUPDATE文を記述します。ここでは、どのレコードを更新対象とするかを特定するためのWHERE句の重要性を解説します。削除（Delete）に関しては、不要になったToDo項目を物理的に削除するためのDELETE文を設計します。授業では、これらのSQL文を設計する際に、前回までに作成したデータベースのテーブル定義（todosテーブルのカラム構造やデータ型）と整合性を取ることの重要性を強調します。また、SQLインジェクションなどのセキュリティリスクを回避するために、リテラル値を直接SQL文字列に埋め込むのではなく、プレースホルダを使用したパラメータ化クエリの形式で設計する必要があることを説明します。MyBatisにおいては、このパラメータ化がフレームワークによってサポートされており、SQL設計段階から変数を意識した記述が求められることを理解させます。さらに、各SQL文が実行された際にデータベース内でどのようなトランザクション処理が行われるか、コミットやロールバックの基本概念にも触れつつ、正しいデータ操作を行うための論理的な思考力を養います。この細目で理解すべき範囲は、CRUD操作の各概念に対応する標準的なSQL文の構文と、アプリケーション固有のテーブル構造に基づいたクエリ設計まで。
|
③ 本細目では、設計したSQL文とJavaのRepositoryインターフェースを紐づけるためのMapper XMLファイルの作成と実装詳細について詳説します。MyBatisにおいて、SQL文をJavaコードから分離してXMLファイルに記述することは、保守性や可読性を高める上で重要なプラクティスです。まず、XMLファイルの配置場所（src/main/resources配下）と、MyBatisの設定ファイルとしての基本的な構造（DOCTYPE宣言やルート要素）について解説します。特に、ルート要素である`＜mapper＞`タグの`namespace`属性が極めて重要であり、ここにRepositoryインターフェースの完全修飾名（パッケージ名を含むクラス名）を記述することで、インターフェースとXMLファイルが一対一に対応づけられる仕組みを詳細に説明します。次に、各CRUD操作に対応するXMLタグ（`＜select＞`, `＜insert＞`, `＜update＞`, `＜delete＞`）の使用方法を学びます。各タグの`id`属性には、対応するインターフェースのメソッド名を正確に記述する必要があり、これが不一致であると実行時エラーが発生することを警告します。また、`resultType`属性を用いて、SQLの実行結果（ResultSet）をJavaのEntityオブジェクトに自動的にマッピングする設定方法について解説します。ここでは、データベースのカラム名とJavaクラスのフィールド名が一致している場合にMyBatisが自動的に値をセットする仕組みや、キャメルケースとスネークケースの変換設定についても触れます。さらに、SQL文内でのパラメータの扱い方として、`#{変数名}`という記法を用いたバインド変数の記述方法を実践します。この記法により、メソッドの引数として渡されたオブジェクトのプロパティ値が、安全にSQLのプレースホルダに置換されるプロセスを理解させます。授業では、実際にXMLファイルを作成し、全件取得、1件取得、登録、更新、削除のすべての操作に対する記述を完成させます。最後に、XMLの記述ミス（タグの閉じ忘れやスペルミス）が引き起こす典型的なエラーとそのデバッグ方法についても言及し、正確な記述能力を涵養します。この細目で理解すべき範囲は、Mapper XMLファイルの構造理解から、namespaceや各タグの設定、パラメータバインドを用いた具体的なマッピング実装まで。
|
|
キーワード
|
① Repository ② Mapperインターフェース ③ プレースホルダ ④ resultType ⑤ namespace
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で作成したRepositoryインターフェースとMapper XMLファイルの記述内容を改めて見直し、Javaのメソッド定義とXML内のSQL定義がどのように対応しているかを一行ずつ確認してください。特に、`namespace`属性によるインターフェースとの紐づけや、メソッド名とタグの`id`属性の一致、引数オブジェクトのフィールドとSQL内の`#{}`記法の対応関係について、図を描くなどして整理することを推奨します。また、CRUDの各操作に対応するSQL構文が正しく記述されているか、テーブル定義書と照らし合わせて確認してください。
◆次回授業の予習
次回の授業では、今回作成したデータアクセス層を利用して、ビジネスロジックを実装する「Service層」の開発を行います。予習として、Webアプリケーションにおける「ビジネスロジック」とは具体的にどのような処理を指すのか（例：データの加工、トランザクション管理、複数テーブルへの操作の組み合わせなど）、一般的な概念を整理しておいてください。また、Javaのインターフェースと実装クラスを分ける設計パターン（ServiceインターフェースとServiceImplクラス）のメリットについて、これまでの学習内容を振り返り考察してください。
|
|
33
|
ビジネスロジック層の実装（Service）
|
科目の中での位置付け
|
本講義は、全45回にわたるWebアプリケーション開発演習の第33回目であり、第6部「実践アプリケーション開発（ToDoアプリ）」の中核を成す重要な回である。前回までに構築したデータベース層（Repository）と、次回以降に構築するプレゼンテーション層（Controller）を繋ぐ「ビジネスロジック層（Service）」の実装を行う。これにより、アプリケーションの主要な機能であるToDo管理処理の実体を作成し、レイヤ化アーキテクチャにおける各層の責務分担と連携を完成形へと近づける位置づけにある。
|
|
|
コマ主題細目
|
① Serviceインターフェースの設計と定義 ② ServiceImplクラスの実装と依存性注入 ③ 宣言的トランザクション管理の概念と適用
|
|
細目レベル
|
① 本細目では、ドメイン層の中核となるServiceインターフェースの役割と設計手法について、学術的な背景を踏まえつつ詳細に解説し、実践的な実装を行う。まず、Webアプリケーション開発における「ビジネスロジック」の定義について再確認する。ビジネスロジックとは、システムが提供する業務機能そのものであり、データの加工、計算、検証、そしてデータベース操作の制御などを指す。Spring Frameworkを用いたレイヤ化アーキテクチャにおいて、これらのロジックはControllerやRepositoryに記述するのではなく、独立したService層に集約させることが推奨されている。この「関心の分離」がいかに保守性や可読性を高めるかについて、具体的な事例を交えて学生に理解させる。
次に、なぜServiceクラスを直接実装するのではなく、まずインターフェース（Service Interface）を定義する必要があるのかについて、オブジェクト指向プログラミングの観点から詳説する。第2部および第3部で学習した「依存性の注入（DI）」の原則に立ち返り、インターフェースに対するプログラミング（Programming to an Interface）を行うことで、実装クラスの変更が利用側（この場合はController）に影響を与えない「疎結合」な設計が可能になることを解説する。また、これによりテスト時のモック化が容易になる点など、開発プロセス全体におけるメリットについても触れる。
続いて、ToDoアプリケーションに必要な具体的な機能要件に基づき、Serviceインターフェースに定義すべきメソッドを設計する。具体的には、全件取得（findAll）、主キー検索（findById）、新規登録（insert）、更新（update）、削除（deleteById）といったCRUD操作に対応するメソッドシグネチャを定義する。この際、引数として受け取るデータ型（EntityやID）と、戻り値として返すべきデータ型（ListやEntity、voidなど）の選定理由について論理的に説明し、データフローを意識した設計能力を涵養する。最後に、Eclipse等のIDEを用いて実際にJavaのインターフェースファイルを作成し、抽象メソッドとしてこれらの操作を記述する演習を行う。この細目で理解すべき範囲は、ビジネスロジック層の役割を理解し、適切なメソッド定義を持つServiceインターフェースを作成するまで。
|
② 本細目では、前段で定義したServiceインターフェースを具体的に実装するクラス（ServiceImpl）の作成を行い、Spring FrameworkのDIコンテナ管理下にあるコンポーネントとして機能させる手法を詳説する。まず、作成したクラスに対してインターフェースをimplementsし、Javaの文法規則に従ってすべての抽象メソッドをオーバーライドする枠組みを作成する。その上で、このクラスが単なるJavaクラスではなく、Springによって管理される「Service」であることを示すために、ステレオタイプアノテーションである「@Service」を付与する意味について解説する。第11回で学んだコンポーネントスキャンの仕組みを振り返り、このアノテーションが付与されることで、Spring起動時に自動的にインスタンス化され、DIコンテナに登録されるプロセスを学生に想起させる。
次に、ビジネスロジックを実行するために不可欠なデータベースアクセス機能の利用方法について学ぶ。Service層は自らSQLを発行するのではなく、前回作成したRepository層（Mapper）に処理を委譲する。この連携を実現するために、RepositoryインターフェースをServiceクラスのフィールドとして宣言し、DI（依存性の注入）を行う手法を実践する。ここでは、Lombokライブラリの「@RequiredArgsConstructor」を用いたコンストラクタインジェクションの手法を採用し、final修飾子を用いたイミュータブルな依存関係の構築が推奨される理由（循環参照の防止やテストの容易性など）を改めて強調する。
続いて、各メソッドの具体的な処理ロジックを実装する。例えば、findAllメソッドであればRepositoryのselectAllメソッドを呼び出してその結果をそのまま返す処理、insertメソッドであれば引数のEntityをRepositoryのinsertメソッドに渡す処理などを記述する。現段階では単純な委譲（パススルー）処理が主となるが、将来的に入力値の加工や複雑な計算が必要になった場合、このService層こそがその記述場所となることを説明し、アーキテクチャ上の責務分担を深く理解させる。学生には、Controllerからデータを受け取り、Serviceで処理し、Repositoryを経てデータベースへ到達するという一連のデータフローをコードレベルで明確にイメージさせる。この細目で理解すべき範囲は、Serviceの実装クラスを作成し、Repositoryを注入してCRUD処理を委譲する実装を完了するまで。
|
③ 本細目では、業務アプリケーションにおいてデータの整合性を保つために不可欠な「トランザクション管理」の概念と、Spring Frameworkにおける実装方法について詳説する。まず、トランザクションとは何かについて、解説する。トランザクションとは、複数の処理をひとまとめにした不可分な単位であり、「すべて成功するか、すべて失敗（取り消し）するか」のいずれかの状態しか許さないというACID特性（特に原子性）について、銀行口座の振込処理（出金と入金）などの具体的な例を用いて直感的に理解させる。ToDoアプリにおいても、将来的に複数のテーブルを同時に更新するような要件が発生した場合、途中でエラーが発生してもデータ矛盾が起きないように制御する必要があることを説明する。
次に、「トランザクション境界」という概念について解説する。Webアプリケーションの3層構造において、どこでトランザクションを開始し、どこで終了（コミットまたはロールバック）すべきかという問題である。一般的に、ビジネスロジックの単位であるService層のメソッドがトランザクション境界として適切であることを説明する。ControllerはWebの処理、Repositoryは単一のSQL実行を担当するため、業務としての一まとまりを表現するService層で制御するのが論理的であるためである。
続いて、Spring Frameworkが提供する「宣言的トランザクション管理」の強力な機能である「@Transactional」アノテーションについて詳説する。従来のJDBCプログラミングでは、明示的にcommitやrollbackメソッドを呼び出すコードを記述する必要があり、これがコードの複雑化やバグの温床となっていた。しかし、Springでは第4部で学んだAOP（アスペクト指向プログラミング）の技術を利用し、アノテーションを付与するだけで、メソッドの開始時にトランザクションを開始し、正常終了時にコミット、例外発生時にロールバックするという横断的な処理を自動的に織り込むことができる。この仕組みを理解させた上で、実際にServiceクラスまたは各メソッドに@Transactionalアノテーションを付与する演習を行う。これにより、学生は複雑なトランザクション制御を極めて簡潔に実装できるフレームワークの恩恵を実感する。この細目で理解すべき範囲は、トランザクションの概念を理解し、@Transactionalを用いてService層に適切なトランザクション制御を適用するまで。
|
|
キーワード
|
① Serviceインターフェース ② ServiceImplクラス ③ ビジネスロジック ④ トランザクション境界 ⑤ @Transactional
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で実装したService層が、アプリケーション全体の中でどのような役割を果たしているかを再確認すること。特に、インターフェースと実装クラスを分離することのメリットや、Repository層との連携方法（DI）について、これまでの講義資料やノートを見返して整理しておくこと。また、トランザクション管理がなぜ必要なのか、もしトランザクション制御を行わなかった場合にどのようなデータ不整合のリスクがあるかについて、具体的なシナリオを想像しながら論理的に説明できるように思考を整理しておくこと。
◆次回授業の予習
次回は、ユーザーからのリクエストを受け付ける「プレゼンテーション層（Controller）」の実装を行う。これに向けて、Spring MVCにおけるリクエスト処理の流れ（DispatcherServletからControllerへのディスパッチ）や、Controllerクラスで使用する主要なアノテーション（@Controller, @RequestMapping, @GetMapping, @PostMappingなど）の役割について、テキストの該当箇所（第5部）を読み返して予習しておくこと。また、画面（View）とコントローラー（Controller）の間でどのようにデータが受け渡されるか、Modelオブジェクトの役割についても確認しておくと理解がスムーズになる。
|
|
34
|
アプリケーション層の実装①
|
科目の中での位置付け
|
本講義は、全45回にわたるWebアプリケーション開発演習の第34回目であり、第6部「実践アプリケーション開発」の中盤に位置します。これまでの講義で構築してきたデータベース層（Repository）およびビジネスロジック層（Service）の上に、ユーザーとの対話を担うアプリケーション層（ControllerとView）を実装する重要な段階です。本コマでは、Webアプリケーションの基本機能である「参照（Read）」機能の実装を通じて、MVCモデルにおけるデータの流れとレイヤ間の連携を統合的に理解します。
|
|
|
コマ主題細目
|
① Controllerクラスの作成とDIによるService利用 ② 一覧表示機能の実装とThymeleafによるリスト描画 ③ 詳細表示機能の実装と動的URLパラメータの処理
|
|
細目レベル
|
① 本主題では、MVCモデルにおける司令塔の役割を果たすControllerクラスを作成し、ビジネスロジック層との連携基盤を構築します。まず、`com.example.demo.controller`パッケージ配下に`ToDoController`クラスを新規作成します。このクラスには、Spring MVCのコントローラであることを示す`@Controller`アノテーションを付与します。このアノテーションにより、Spring Frameworkの起動時に実行されるコンポーネントスキャンの対象となり、自動的にBeanとしてDIコンテナに登録されるとともに、WebブラウザからのHTTPリクエストを受け付けるハンドラとしての機能を持ちます。
次に、前回の講義で作成した`ToDoService`をこのコントローラ内で利用可能にするための設定を行います。これは、DI（依存性の注入）の概念を実践する場面です。コントローラクラスのフィールドとして`ToDoService`型の変数を宣言し、これを介してビジネスロジックを呼び出せるようにします。ここでは、Spring Frameworkで推奨されているコンストラクタインジェクションを採用します。具体的には、Lombokライブラリが提供する`@AllArgsConstructor`（または`@RequiredArgsConstructor`）アノテーションをクラスに付与することで、コンストラクタの記述を省略しつつ、安全に依存オブジェクトを注入する手法を学びます。これにより、開発者は煩雑な初期化コードを書くことなく、必要なサービスを利用できる状態になります。
さらに、コントローラ内のメソッド（ハンドラメソッド）の基本的な構造についても解説します。ハンドラメソッドは、特定のリクエストURLに対応して実行され、処理結果として「ビュー名（HTMLファイルの名前）」を返却するというSpring MVCの規約を理解させます。この段階では、まだ具体的な処理の中身までは踏み込まず、クラスの枠組みと、Service層への依存関係が正しく設定されていることを確認することに重点を置きます。学生には、レイヤ化アーキテクチャにおいて、Controllerは自ら複雑なビジネスロジックを実行するのではなく、Service層に処理を委譲し、その結果を受け取ってViewに渡すという「仲介役」に徹すべきであるという設計思想を深く理解させます。
この細目で理解すべき範囲は、`@Controller`を用いたクラス定義から、Lombokを活用したServiceのDI、およびハンドラメソッドの基本構造の理解まで。
|
② 本主題では、登録されているToDoデータを全件取得し、ブラウザ上に一覧表示する機能を実装します。まず、コントローラクラスに一覧画面表示用のハンドラメソッドを作成します。このメソッドには`@GetMapping("/todo")`アノテーションを付与し、`/todo`というURLに対するGETリクエストを処理するようにマッピングします。メソッド内部では、DIされた`ToDoService`の`findAllToDo()`メソッドを呼び出し、データベースに格納されているすべてのToDoデータをリスト形式で取得します。
ここで重要となるのが、取得したデータをどのようにしてView（画面）へ受け渡すかという点です。Spring MVCでは、`Model`インターフェースを利用します。ハンドラメソッドの引数に`Model`を宣言し、その`addAttribute`メソッドを使用して、取得したToDoリストを任意のキー名（例："todoList"）で格納します。これにより、データはRequestスコープに保持され、遷移先のViewから参照可能となります。
続いて、View層の実装に移ります。`src/main/resources/templates`配下に`todo`フォルダを作成し、その中に`list.html`を作成します。HTMLファイルでは、テンプレートエンジンThymeleafを利用するための名前空間宣言を行います。一覧表示の核となるのは、Thymeleafの繰り返し処理属性`th:each`です。HTMLの`＜tr＞`タグなどに`th:each="todo : ${todoList}"`と記述することで、Controllerから渡されたリストの要素数分だけタグが繰り返される仕組みを解説します。
ループ内部では、`th:text="${todo.title}"`のように記述し、各ToDoオブジェクトのプロパティ値を動的にHTMLテキストとして出力します。また、完了期限や優先度といった他の項目についても同様に表示設定を行います。さらに、詳細画面へ遷移するためのリンクも設定しますが、これについては次項で詳述するため、ここでは静的な枠組みとデータの埋め込みに注力します。学生には、Javaのコードで取得したデータが、Modelを経由してHTMLテンプレートに統合され、最終的にブラウザで閲覧可能なHTMLとして生成されるまでの一連のデータフローを明確にイメージさせます。
この細目で理解すべき範囲は、`@GetMapping`によるリクエストマッピング、Modelによるデータ受け渡し、およびThymeleafの`th:each`を用いたリスト表示の実装まで。
|
③ 本主題では、一覧画面から特定のToDoを選択し、その詳細情報を表示する機能を実装します。これには、URLの一部をパラメータとして扱うRESTfulな設計手法と、動的な画面遷移の技術が必要となります。
まず、一覧画面（`list.html`）において、各ToDoのタイトル等を詳細画面へのリンクに変更します。Thymeleafのリンク式`@{...}`を使用し、URLの中に各ToDoのIDを埋め込む方法を学びます。具体的には、`@{/todo/__${todo.id}__}`のような記述を用いることで、`todo/1`や`todo/2`といった、IDごとに異なるユニークなURLを動的に生成できることを理解させます。
次に、コントローラ側でこの動的なURLを受け取る処理を実装します。ハンドラメソッドに`@GetMapping("/todo/{id}")`を付与し、URLパス内の`{id}`部分を可変の値として定義します。そして、メソッドの引数に対して`@PathVariable("id")`アノテーションを使用することで、URLに含まれるIDの値をJavaの変数として取得できる仕組みを解説します。これは、クエリパラメータ（`?id=1`）とは異なる、リソース指向のURL設計における標準的な手法です。
取得したIDを用いて、`ToDoService`の`findById(id)`メソッドを呼び出し、該当するToDoデータを一件取得します。取得したデータは、一覧表示と同様に`Model`に格納してViewへ渡します。View側では、新規に`detail.html`を作成し、受け取った単一のToDoオブジェクトの情報を`th:text`を用いて表示します。ここでは、リスト表示とは異なり、ループ処理を行わずにオブジェクトの各フィールドに直接アクセスして表示する方法を確認します。
最後に、詳細画面から一覧画面へ戻るためのリンクを設置し、画面間の相互移動がスムーズに行えることを確認します。この一連の実装を通じて、Webアプリケーションにおける「画面遷移」と「コンテキスト（文脈）の維持」がどのように実現されているかを学びます。特に、IDというキー情報が、View（リンク）→Controller（パス変数）→Service（引数）→Database（検索条件）とバケツリレーのように渡されていくデータの流れを深く理解させることが重要です。
この細目で理解すべき範囲は、Thymeleafによる動的リンク生成、`@PathVariable`を用いたパス変数の取得、および詳細画面のView実装まで。
|
|
キーワード
|
① Controller ② @GetMapping ③ @PathVariable ④ Model ⑤ URLの動的生成
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で作成したControllerクラスとHTMLファイルを読み返し、ブラウザで一覧画面が表示されるまでの処理の流れをノートに整理してください。特に、ControllerがServiceから受け取ったデータが、どのような仕組み（Modelインターフェース）を使ってHTML側に渡り、Thymeleafのどのタグによって画面に描画されているか、データの変遷を一行ずつ追跡することをお勧めします。また、詳細画面へのリンクをクリックした際、URLに含まれるIDがどのようにしてControllerに伝わり、データベース検索に使われるかをコード上で確認してください。
◆次回授業の予習
次回の授業では、アプリケーションに新しいToDoを追加する「新規登録機能」を実装します。これには、Webブラウザからサーバーへデータを送信する仕組みの理解が必要です。これまでの授業で学んだHTTPメソッドの「GET」と「POST」の違いについて復習しておいてください。特に、HTMLのフォーム（`＜form＞`タグ）からデータを送信する際にPOSTメソッドが使われる理由や、データがリクエストボディに含まれて送信される仕組みについて、第4回や第21回の資料を見直して知識を整理しておくことが望ましいです。
|
|
35
|
アプリケーション層の実装②
|
科目の中での位置付け
|
本講義は、Spring Frameworkを用いたWebアプリケーション開発演習の第6部「実践アプリケーション開発」の第6回目にあたる。前回実装したToDoアプリの一覧・詳細表示機能（参照系）に続き、今回はデータの新規作成機能（更新系）を実装する。これはWebアプリケーションの基本機能であるCRUD（Create, Read, Update, Delete）のうち、Create（作成）に相当する重要なフェーズである。ここでは、クライアントからのデータ送信（POSTメソッド）、アプリケーション層でのデータ受け取りと変換、そして処理完了後の画面遷移（リダイレクト）という、Web開発における標準的なデータ処理フローを確立する。これにより、静的なデータ表示から動的なデータ操作へとアプリケーションを進化させ、次回の更新処理実装への基盤を築く。
|
|
|
コマ主題細目
|
① 入力データ用Formクラスと変換用Helperクラスの実装 ② Controllerにおける新規登録処理とリダイレクト制御 ③ Thymeleafによる登録画面の作成と一連の動作検証
|
|
細目レベル
|
① 本細目では、クライアント（ブラウザ）の入力フォームから送信されるデータを受け取るための専用クラスであるFormクラスと、そのデータをドメイン層やインフラストラクチャ層で扱うEntityクラスへ変換するためのHelperクラスの実装について詳説する。まず、なぜデータベースのテーブル定義に対応するEntityクラスをそのまま画面入力用に使用せず、別途Formクラスを作成する必要があるのか、そのアーキテクチャ上の意義について学生に深く理解させる。具体的には、画面固有の入力要件（バリデーションや表示形式）とデータベースの永続化要件を分離することで、各層の責務を明確化し、保守性を高めるという設計思想を解説する。「FormとEntityの違い」について、Formクラスは画面からの入力値を保持する単なるコンテナ（POJO）として定義し、Lombokのアノテーションを活用してボイラープレートコードを削減する方法を指導する。
次に、FormクラスからEntityクラスへのデータ変換を行うHelperクラスの実装を行う。Controllerクラス内に変換ロジックを直接記述するとコードが肥大化し可読性が低下するため、変換処理を専門に行うHelperクラスを導入することで、Controllerの役割を「リクエストの制御」に集中させる設計手法を学ぶ。ここでは、Formオブジェクトを受け取り、新しいEntityオブジェクト（ToDo）を生成して返すメソッドを実装させる。この過程で、Javaのオブジェクト指向的なデータの取り扱いと、各クラス間のデータの流れ（Data Flow）を意識させ、SpringのDIコンテナ管理下には置かないPOJOとしてのクラス設計と、必要に応じて`@Component`等を付与してDI管理下に置く設計の選択についても触れつつ、テキストの実装方針に沿って解説を進める。学生には、単にコードを写すのではなく、データの入れ物（Form）とデータの変換役（Helper）という役割分担を明確に意識させ、疎結合なコード記述の能力を涵養する。
この細目で理解すべき範囲は、FormクラスとEntityクラスの役割の違いを理解し、FormクラスおよびHelperクラスのJavaコードを実装して、データ変換の準備が整うところまで。
|
② 本細目では、作成したFormクラスとHelperクラスを利用して、新規登録機能を実現するためのControllerの実装について詳説する。ここでは、画面を表示するためのGETリクエスト処理と、フォームからの送信を受け取るPOSTリクエスト処理の2つのメソッドを実装する。まず、登録画面を表示するGETメソッドにおいては、`@GetMapping`アノテーションを使用し、Thymeleafのフォームバインディングに対応するために、空のFormオブジェクトを生成してModelに格納する処理を解説する。これにより、View側で`th:object`を用いてフォームとオブジェクトを紐付ける準備が整うことを理解させる。
次に、登録処理を実行するPOSTメソッドの実装を行う。`@PostMapping`アノテーションを使用し、引数としてFormオブジェクトを受け取ることで、Spring MVCがリクエストパラメータを自動的にFormクラスのフィールドにマッピングする仕組み（データバインディング）を解説する。続いて、Helperクラスを用いてFormをEntityに変換し、前回までに作成したServiceクラスの登録メソッドを呼び出してデータベースへの保存を行う一連の処理フローを実装させる。
さらに、この細目における極めて重要な概念として、処理完了後の画面遷移における「リダイレクト」の重要性を詳説する。データの更新処理後に単に画面（View）を返す（フォワードする）のではなく、`redirect:/todos`のようにリダイレクトを指示することで、ブラウザのアドレスバーを更新し、ユーザーが「更新ボタン」を押した際の二重送信（二重登録）を防止する「PRG（Post-Redirect-Get）パターン」について解説する。Webアプリケーションにおけるユーザー体験（UX）とデータの整合性を保つために、更新系処理の後には必ずリダイレクトを行うという定石を学生に強く意識させ、その実装方法を習得させる。
この細目で理解すべき範囲は、ControllerにGET用とPOST用のメソッドを追加し、Formデータの受け取り、Serviceの呼び出し、そして処理完了後のリダイレクトまでの一連の制御ロジックを実装するところまで。
|
③ 本細目では、ユーザーがデータを入力するための新規登録画面（View）をThymeleafを用いて作成し、アプリケーション全体としての動作確認を行う。まず、HTMLファイルを作成し、`＜form＞`タグを用いた入力フォームの構築方法について詳説する。特に、Thymeleafの属性である`th:action`による送信先URLの指定、`th:object`によるFormオブジェクトのバインディング、そして`th:field`による各入力項目（inputタグやtextareaタグ）とFormクラスのフィールドとの紐付けについて重点的に解説する。`th:field`を使用することで、HTMLの`id`属性、`name`属性、`value`属性が自動的に生成される仕組みを理解させ、手動で属性を記述する場合と比較して記述ミスが減り、保守性が向上するメリットを認識させる。
画面の実装が完了した後、アプリケーションを起動し、ブラウザを通じて一連の動作検証を行う実践的な演習を実施する。具体的には、一覧画面から「新規登録」リンクをクリックして登録画面へ遷移し、タイトルや詳細を入力して「登録」ボタンを押下する。その後、POST送信が行われ、Controllerでの処理を経て一覧画面へリダイレクトされ、一覧に新しいToDoアイテムが追加されていることを確認するプロセスを体験させる。
さらに、単に画面上で確認するだけでなく、PostgreSQLの管理ツール（pgAdmin等）を使用してデータベースのテーブルを直接参照し、入力したデータが正しくレコードとして永続化されていることを確認するよう指導する。これにより、画面（View）、制御（Controller）、ビジネスロジック（Service）、データアクセス（Repository）、データベース（DB）というレイヤ化アーキテクチャの全層をデータが貫通し、正しく処理されたことを客観的に検証する能力を養う。また、登録後にブラウザの「戻る」ボタンや「更新」ボタンを操作した際の挙動を確認させ、前述のリダイレクトによる二重送信防止の効果を実体験として理解させる。
この細目で理解すべき範囲は、Thymeleafを用いた入力フォーム画面の作成、ブラウザでの操作による登録機能の確認、およびデータベースレベルでのデータ永続化の確認まで。
|
|
キーワード
|
① Formクラス ② Helperクラス ③ リダイレクト ④ @ModelAttribute ⑤ th:object
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で実装した新規登録機能におけるデータの流れ（View → Controller → Helper → Service → Repository → DB）をノートに図解し、整理すること。特に、なぜEntityクラスを直接Controllerの引数にせず、Formクラスを介在させるのか、その理由とHelperクラスの役割について自分の言葉で説明できるようにすること。また、POST送信後のレスポンスとしてHTMLを直接返すのではなくリダイレクトを使用する理由（PRGパターン）について、二重送信のリスクの観点から再確認しておくこと。
◆次回授業の予習
次回の授業では、既存のデータを変更する「更新処理」を実装するため、今回学んだ登録処理との共通点と相違点を意識して整理しておくこと。具体的には、更新処理では「どのデータを更新するか」を特定するためにIDが必要になる点や、編集画面を開いた際に初期値として現在のデータが表示されている必要がある点など、登録処理とは異なる要件が発生することを想定しておくこと。また、WebアプリケーションにおけるHTTPメソッド（GETとPOST）の役割の違いについて改めて確認しておくこと。
|
|
36
|
アプリケーション層の実装③
|
科目の中での位置付け
|
本講義は、全45回にわたるWebアプリケーション開発演習の第36回目であり、第6部「実践アプリケーション開発」の中盤に位置します。前回までに実装したToDoアプリの「一覧表示」「詳細表示」「新規登録」に続き、本講義ではCRUD機能の構成要素である「更新（Update）」の実装を行います。既存データの取得から編集、データベースへの反映という一連のプロセスを通じて、Webアプリケーションにおけるデータ操作の完全性を高める重要なステップとなります。
|
|
|
コマ主題細目
|
① 更新画面への遷移と初期データ表示の実装 ② データベース更新処理とリダイレクト制御 ③ Helperクラスによる責務分離とViewの共通化
|
|
細目レベル
|
① 本細目では、既存のToDoデータを編集するための画面を表示するプロセスについて詳説します。まず、一覧画面や詳細画面から更新画面へ遷移する際のリクエスト設計について解説します。更新処理においては、どのデータを編集するのかを特定するために、URLに識別子（ID）を含める必要があります。Spring MVCにおける@PathVariableアノテーションを使用し、URLパスの一部として埋め込まれたIDをControllerのメソッド引数として受け取るメカニズムを学習します。
次に、受け取ったIDを用いて、Service層およびRepository層を経由し、データベースから該当するEntity（ドメインオブジェクト）を取得する処理を実装します。ここで重要な概念として、データベースの構造を反映したEntityをそのまま画面表示に使用するのではなく、画面入力専用のFormクラスへデータを詰め替える手順について解説します。このデータ変換は、データベース層とプレゼンテーション層の結合度を下げ、セキュリティや保守性を向上させるために推奨される設計パターンです。具体的には、取得したEntityの各フィールド値を、対応するFormオブジェクトのフィールドにコピーし、そのFormオブジェクトをModelに格納します。
さらに、Thymeleafテンプレートエンジンを用いて、Modelに格納されたFormオブジェクトの値をHTMLフォームの初期値として表示する方法を実践します。特に、テキストボックスやテキストエリアに既存の値をプリセットすることで、ユーザーが現在の登録内容を確認しながら修正を行えるようにするユーザーインターフェースの実装詳細を学びます。また、更新処理の実装において不可欠な要素である「IDの保持」についても触れます。画面上には表示する必要がないものの、後の更新実行時にレコードを一意に特定するために必要なIDを、HTMLのhiddenフィールドとしてフォーム内に埋め込む技術的な理由と実装方法を解説します。これにより、ステートレスなHTTP通信において、画面遷移間で特定のデータコンテキストを維持するための基本的な手法を習得させます。
この細目で理解すべき範囲は、リクエストパラメータからのID取得、DBからのデータ検索、Formクラスへのデータ変換、および更新画面への初期値表示まで。
|
② 本細目では、ユーザーによって編集されたデータをサーバーで受け取り、データベースへ反映させる一連の更新実行処理について詳説します。まず、HTMLフォームからPOSTメソッドで送信されたリクエストをControllerで受信する方法を学びます。Spring MVCのデータバインディング機能により、フォームの入力値が自動的にFormクラスのインスタンスにマッピングされる仕組みを再確認し、開発者が手動でリクエストパラメータを解析する必要がない点の生産性の高さを理解させます。
次に、受信したFormオブジェクトを、ビジネスロジック層で処理可能なEntityオブジェクトへと変換するプロセスを解説します。この変換処理は、前述の初期表示時とは逆の方向へのデータ移行となります。変換されたEntityオブジェクトを引数としてService層の更新メソッドを呼び出し、最終的にMyBatisのMapper XMLに定義されたUPDATE文が実行されるまでのデータフローを追跡します。ここでは、Service層におけるトランザクション境界の役割についても振り返り、データ整合性がどのように保たれているかを意識させます。
さらに、更新処理完了後のレスポンス制御として、リダイレクト処理の重要性を詳説します。更新処理の直後に単に完了画面のViewを返すのではなく、リダイレクト（PRGパターン：Post-Redirect-Get）を用いる理由について、二重送信（ダブルサブミット）の防止という観点から論理的に説明します。ブラウザの更新ボタンによる意図しない再POSTを防ぎ、データの一貫性を守るためのWebアプリケーションにおける標準的な作法であることを強調します。具体的には、Controllerのメソッドの戻り値としてredirect:/todoのような文字列を返すことで、クライアントブラウザに対して新たなGETリクエストを促し、一覧画面へ遷移させる実装を行います。これらを通じて、安全かつ確実なデータ更新フローを構築する能力を養います。
この細目で理解すべき範囲は、POSTリクエストによるデータ受信、Entityへの変換、Service層を通じたDB更新実行、および処理完了後のリダイレクト実装まで。
|
③ 本細目では、アプリケーションの保守性と可読性を向上させるための設計テクニックとして、Helperクラスの導入とViewテンプレートの共通化について詳説します。まず、Controllerクラスの役割を「リクエストの振り分け」に集中させるため、データ変換ロジックを別クラスに切り出す手法を学びます。具体的には、EntityとFormオブジェクトの相互変換を行うメソッド群（convertEntityToFormおよびconvertFormToEntityなど）を持つHelperクラスを作成し、ControllerからこのHelperを利用する構成とします。これにより、Controller内に煩雑なgetter/setterの羅列が記述されることを防ぎ、コードの見通しを良くする「責務の分離（Separation of Concerns）」の概念を実践的に理解させます。Helperクラスは@Componentアノテーションを付与してDIコンテナに管理させ、Controllerにインジェクションして利用する形をとります。
次に、新規登録画面と更新画面のHTMLテンプレート（View）を共有化する手法について解説します。これら二つの画面は、入力項目やレイアウトがほぼ同一であるため、別々のファイルとして作成すると修正時の二重管理が発生します。これを避けるため、単一のThymeleafテンプレートファイルを使用し、状況に応じて表示内容を動的に切り替える方法を習得します。具体的には、Thymeleafのth:ifやth:unless属性、あるいは三項演算子を用いて、Modelに含まれるデータの状態（例えばIDが存在するか否か）を判定し、ページタイトルを「新規登録」または「編集」に切り替えたり、フォームの送信先URL（action属性）やボタンのラベルを動的に変更したりする実装を行います。また、共通化に伴い、フォーム送信時のHTTPメソッドやhiddenフィールドの扱いがどのように変化・共通化されるかについても詳細に分析します。このようにViewを部品化・共通化することは、DRY（Don't Repeat Yourself）原則の実践であり、効率的な開発において不可欠なスキルであることを強調します。
この細目で理解すべき範囲は、Helperクラスによるデータ変換ロジックの分離、DIによるHelperの利用、およびThymeleafの制御構文を用いた登録・更新画面のテンプレート共有化まで。
|
|
キーワード
|
① @PathVariable ② Helperクラス ③ hiddenフィールド ④ データバインディング ⑤ リダイレクト
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で扱った更新処理のデータフロー（画面表示から更新実行まで）を、ノートに図解して整理してください。特に、Controller、Service、Repository、Helper、Viewの各コンポーネントがどの順番で呼び出され、データ（EntityやForm）がどのように変換されて渡っていくかを明確に記述してください。また、更新処理においてリダイレクトを使用する理由を、具体的なトラブル事例（二重送信など）を想定して自分の言葉で説明できるようにまとめてください。
◆次回授業の予習
次回の授業では、ToDoアプリのデータ削除機能を実装します。Webアプリケーションにおいてデータを削除する際、ユーザーが誤って削除しないようにするためのUI/UX上の工夫（確認ダイアログの表示など）にはどのようなものがあるか、一般的なWebサービスを例に考えてみてください。また、データベースのレコードを削除するSQL文（DELETE文）の基本的な構文と、削除条件（WHERE句）の重要性について、これまでのデータベース学習の内容を振り返っておいてください。
|
|
37
|
アプリケーション層の実装④
|
科目の中での位置付け
|
本講義は、Spring Frameworkを用いたWebアプリケーション開発演習の第37回目であり、第6部「実践アプリケーション開発（ToDoアプリ）」の構成要素である。これまでに実装した新規登録、一覧表示、詳細表示、更新機能に加え、本講義で削除機能を実装することで、データベース操作の基本であるCRUD（Create, Read, Update, Delete）の全ての機能が揃うことになる。これにより、Webアプリケーションにおけるデータのライフサイクル管理の基礎が完成し、実用的なアプリケーションとしての体裁が整う重要な回である。
|
|
|
コマ主題細目
|
① 削除機能の設計とHTTPメソッドの適切な選択 ② View層における削除ボタンの実装とフォーム送信 ③ 削除機能の動作確認とデータライフサイクルの総括
|
|
細目レベル
|
① 本細目では、Webアプリケーションにおけるデータ削除機能の設計思想と、Spring MVCを用いたController層の実装について詳説する。まず、削除処理を実装する際に最も重要となるのが、適切なHTTPメソッドの選択である。HTTPプロトコルにおいて、GETメソッドはリソースの取得を目的としており、サーバー上のデータの状態を変更するような副作用を持つ操作には使用すべきではないという原則がある。もし削除機能をGETリクエスト（単純なハイパーリンク）として実装した場合、検索エンジンのクローラがリンクを辿るだけでデータを削除してしまったり、ユーザーが意図せずリンクをクリックしただけでデータが消失したりする重大なリスクが生じる。したがって、データの削除という不可逆的な副作用を伴う操作には、必ずPOSTメソッドを使用する必要があることを学生に強く認識させる。Web標準のHTMLフォームはGETとPOSTのみをサポートしているため、本演習ではPOSTメソッドを採用する。
次に、Spring MVCのControllerにおける実装詳細について解説する。削除リクエストを受け付けるメソッドには`@PostMapping`アノテーションを付与し、削除対象のデータを特定するための主キー（ID）を引数として受け取るように設計する。このIDは、URLパスの一部として受け取る場合は`@PathVariable`、リクエストパラメータとして受け取る場合は`@RequestParam`を使用するが、ここでは、Service層の削除メソッドを呼び出すための適切な引数処理を実装する。Service層では、以前の講義で実装したRepository経由での物理削除処理が実行されることになる。
さらに、削除処理完了後のレスポンス処理として、リダイレクト（Redirect）の重要性について解説する。削除実行後に単に完了画面のHTMLを返すのではなく、一覧画面へリダイレクトすることで、ブラウザのアドレスバーを一覧画面のURLに変更させる。これは「Post/Redirect/Get（PRG）パターン」と呼ばれるWebアプリケーションの基本的な設計パターンであり、ユーザーがブラウザの更新ボタンを押した際に、削除リクエストが再送信されてしまう二重送信のトラブルを防ぐ効果がある。具体的には、Controllerのメソッドの戻り値として`"redirect:/..."`形式の文字列を返却することで、クライアントに対してHTTPステータスコード302等による再接続を指示する仕組みを理解させる。この細目で理解すべき範囲は、HTTPメソッドの選択理由からControllerによる削除処理の実装、およびリダイレクトによる画面遷移まで。
|
② 本細目では、Thymeleafテンプレートエンジンを用いたView層の実装について、特にHTMLフォームと連携した削除ボタンの作成方法を中心に解説する。前述の通り、削除処理はPOSTメソッドで行う必要があるため、単なるリンクタグ（`＜a＞`）ではなく、`＜form＞`タグを使用して実装する必要があることを具体的に示す。ToDo一覧画面の各行に対して削除ボタンを配置する場合、それぞれの行が独立したフォームとして機能するように実装しなければならない。具体的には、`th:each`による繰り返し処理の中で、各ToDo項目のIDを含んだ個別の`＜form＞`要素を生成し、その内部に送信ボタン（Submit Button）を配置する構造となる。
Thymeleafの`th:action`属性を用いたURLの構築方法について詳説する。削除リクエストの送信先URLには、削除対象のIDを含める必要がある。例えば、パス変数としてIDを渡す場合は、`th:action="@{/todo/delete/{id}(id=${todo.id})}"`のような記述を行い、実行時に各行のToDo IDがURLに動的に埋め込まれる仕組みを理解させる。これにより、どのボタンが押されたかによって、送信先のURLが一意に定まり、Controller側で正しいIDを受け取ることが可能となる。また、フォーム内には`＜button＞`タグまたは`＜input type="submit"＞`タグを配置し、ユーザーのアクションをトリガーとしてPOSTリクエストが送信される一連の流れを整理する。
さらに、ユーザーインターフェース（UI）とユーザーエクスペリエンス（UX）の観点からの配慮についても言及する。削除機能はデータを永久に失う不可逆的な操作であるため、ユーザーが誤って操作しないようなデザイン上の工夫が求められる。例えば、更新ボタンや詳細表示ボタンとは明確に区別できる色（赤色系など）を採用したり、ボタンのラベルを「削除」と明記して操作の結果を予見させたりすることが重要である。テキストでCSSフレームワークを使用している場合は、（例えばBootStrapなどでは）警告や危険を示すスタイルクラス（例：`btn-danger`）を適用することで、視覚的に注意を促す実装を行う。このように、単に機能として削除ができれば良いのではなく、ユーザーが安全かつ快適に利用できるアプリケーションを目指す姿勢を涵養する。最後に、作成したViewがブラウザ上でどのようにレンダリングされ、生成されたHTMLソースコードにおいて`＜form＞`タグの`action`属性や`method`属性が正しく設定されているかを確認する方法についても触れる。この細目で理解すべき範囲は、Thymeleafによるフォームの作成から、UI/UXを考慮したボタンの実装まで。
|
③ 本細目では、実装した削除機能の動作検証手法と、CRUD機能の実装完了に伴うWebアプリケーションにおけるデータのライフサイクルについて総括する。まず、削除機能のテスト手順について具体的に解説する。ブラウザ上でアプリケーションを操作し、一覧画面から任意のToDo項目の削除ボタンを押下する。その後、画面が一覧画面にリダイレクトされ、該当のデータが表示から消えていることを確認する。しかし、画面上から消えているだけでは不十分であり、データベースの実態を確認することが不可欠である。pgAdminなどのデータベース管理ツールを用いて、実際に`todos`テーブルから該当のレコードが物理的に削除されていることを確認する手順を実践させる。これにより、アプリケーションの表示とデータベースの状態が整合していることを確認し、O/Rマッパー（MyBatis）を通じたSQLの実行が正しく行われていることを裏付ける。
次に、これまでの講義で実装してきたCRUD（Create, Read, Update, Delete）機能全体を振り返り、データの一貫した管理について整理する。データは「新規登録」によってデータベースに生成され、「参照」によってユーザーに利用され、「更新」によって状態が変化し、最終的に「削除」によってそのライフサイクルを終える。この一連の流れが、Controller、Service、Repository、そしてデータベースというレイヤ化アーキテクチャの上でどのように処理され、データが受け渡されていくかを再確認する。特に、各機能が独立して存在するのではなく、相互に関連し合いながら一つのアプリケーションを構成している点を強調する。例えば、登録したデータしか削除できない、削除したデータは更新できないといった当然の論理的整合性が、プログラムによってどのように担保されているかを考察させる。
さらに、削除機能における例外的なケースや安全性についても思考を促す。例えば、複数のユーザーが同時に同じデータを操作した場合や、存在しないIDに対して削除リクエストが送信された場合の挙動など、堅牢なアプリケーションを構築するために考慮すべき課題について触れる。今回は基本的な削除機能の実装に留まるが、実務レベルの開発では、論理削除（フラグによる削除扱い）の検討や、排他制御、アクセス権限の確認などが必要になることを示唆し、今後の学習への動機付けを行う。最後に、Spring Frameworkが提供する機能がいかにこれらのCRUD実装を効率化し、開発者がビジネスロジックに集中できる環境を提供しているかを再認識させる。この細目で理解すべき範囲は、削除機能の動作確認方法から、CRUD機能全体の統合的な理解まで。
|
|
キーワード
|
① 削除処理 ② @PostMapping ③ リダイレクト ④ フォーム送信 ⑤ 物理削除
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回実装した削除機能のソースコードを見直し、特にControllerでのPOSTリクエストの受け取り方と、Viewでのフォーム作成部分の記述を重点的に確認すること。また、ブラウザの開発者ツールを使用して、削除ボタンを押した際にどのようなリクエスト（URL、メソッド種別）がサーバーに送信されているかを観察し、講義での解説と実際の挙動を照らし合わせて理解を深めること。
◆次回授業の予習
次回の授業では、アプリケーションの堅牢性を高めるための「バリデーション（入力チェック）」について学習する。Webアプリケーションにおいて、ユーザーからの入力値をサーバー側で検証することの重要性について考えを巡らせておくこと。また、Javaにおけるアノテーションを用いた宣言的なバリデーションの仕組みについて、一般的な概念を調べておくこと。
|
|
38
|
アプリケーションへのバリデーション追加
|
科目の中での位置付け
|
本講義は、これまでに構築したToDo管理アプリケーションに対し、実運用に不可欠な入力値検証（バリデーション）機能を実装する段階に位置します。第24回および第25回で学習したデータ検証の基礎理論と単体での実装技術を、実際のWebアプリケーション開発プロセスに統合・適用することで、不正なデータの登録を防ぎ、システムの堅牢性とデータの整合性を担保する能力を養います。また、エラー発生時の適切なユーザーフィードバックの実装を通じて、ユーザビリティを考慮したアプリケーション設計の重要性を理解する総仕上げの役割も担っています。
|
|
|
コマ主題細目
|
① バリデーション機能の導入準備とFormクラスへの制約定義 ② コントローラ層における検証実行と結果ハンドリングの実装 ③ ビュー層におけるエラーメッセージ表示とUI制御の実装
|
|
細目レベル
|
① 本細目では、Webアプリケーションにおける入力値検証の重要性を再確認し、Spring Frameworkを用いたバリデーションの実装基盤を構築します。まず、ユーザーからの入力データがデータベースに保存される前に、その妥当性を検証することの意義について、データの整合性維持とセキュリティの観点から解説します。不正なデータ（空文字、過剰な文字数、不適切な形式など）がシステム内部に侵入することを防ぐ防波堤としての役割を理解させます。
次に、開発環境における準備として、バリデーション機能を利用するために必要なライブラリの導入手順を実践します。具体的には、プロジェクトのビルド構成ファイル（build.gradle）を確認し、Spring Bootが提供するバリデーション用スターター（spring-boot-starter-validation）が依存関係に含まれているかを確認、あるいは追加する操作を行います。これにより、Bean Validation（Jakarta Validation）の仕様に基づいた標準的なアノテーションが利用可能になる仕組みを解説します。
続いて、データ転送用オブジェクトであるFormクラス（ToDoForm）に対して、具体的な検証ルールを定義する作業を行います。以前に作成したToDoFormクラスを開き、各フィールドに対して適切なアノテーションを付与していきます。例えば、ToDoのタイトルフィールドには、未入力を許容しないための@NotBlankアノテーションや、入力文字数を制限するための@Sizeアノテーションを適用します。また、期限フィールドなどの他の項目についても、要件に応じた制約を設定します。この際、各アノテーションにはmessage属性を指定することで、検証エラー時にユーザーへ表示するためのカスタムメッセージを設定できることを説明し、実際にわかりやすいエラーメッセージを定義させます。このように、ソースコード上のロジックとしてif文を多用するのではなく、フィールドに対するメタデータ（アノテーション）として宣言的に制約を記述することで、コードの可読性と保守性が向上することを強調します。この細目で理解すべき範囲は、バリデーション用ライブラリの導入から、Formクラスへのアノテーションを用いた制約ルールの定義まで。
|
② 本細目では、定義された検証ルールに基づき、実際にサーバーサイドで検証処理を実行し、その結果に応じて処理を分岐させるロジックをコントローラ層に実装します。バリデーションは、クライアントから送信されたリクエストパラメータがFormクラスにバインドされるタイミングで行われることを理解させます。
具体的には、ToDoの新規登録処理および更新処理を担当するControllerクラスのメソッドを修正します。フォームデータを受け取る引数（ToDoForm）の直前に、検証の実行を指示する@Validatedアノテーションを付与します。これにより、Spring MVCはリクエストデータをFormオブジェクトに変換する際、定義されたアノテーション（@NotBlankなど）に基づくチェックを自動的に実行します。
さらに、検証結果を受け取るための重要な仕組みとして、BindingResultインターフェースについて詳説します。BindingResultは、検証対象のオブジェクト（ここではToDoForm）の直後に引数として定義する必要があるというSpring MVCの厳格なルールを解説し、この順序を守らない場合に正しく動作しない理由を、引数解決のメカニズムの観点から説明します。
次に、BindingResultのhasErrorsメソッドを用いた条件分岐の実装を行います。検証の結果、エラーが存在する場合（hasErrorsがtrueを返す場合）は、データベースへの保存処理を行わずに、元の入力画面（登録画面または更新画面）へフォワードさせる処理を記述します。この際、入力されたデータや発生したエラー情報は自動的にModelに格納され、ビューへ引き渡されるため、ユーザーが再入力する手間を省きつつ、何が間違っていたのかを伝える準備が整うことを説明します。一方で、エラーがない場合は、これまで通りService層を呼び出してデータの保存や更新を行い、完了画面や一覧画面へリダイレクトするフローを維持します。このようにして、正常系と異常系の処理フローを明確に分離し、安全なデータのみが永続化層へ渡る仕組みを構築します。この細目で理解すべき範囲は、Controllerメソッドにおける@ValidatedとBindingResultの正しい使用法、および検証結果に基づく条件分岐の実装まで。
|
③ 本細目では、コントローラ層で検知された検証エラーを、ユーザーに対して視覚的に分かりやすく伝達するためのビュー（Thymeleafテンプレート）の実装を行います。エラーが発生して入力画面に戻された際、単に画面が表示されるだけでなく、どの項目でどのようなエラーが発生したのかを具体的に明示することは、ユーザビリティ（使いやすさ）の観点から極めて重要です。
まず、Thymeleafが提供するバリデーションエラー表示用の属性であるth:errorsの使用方法を解説し、実践します。登録画面および更新画面のHTMLファイルを編集し、各入力フィールド（inputタグやtextareaタグ）の近傍に、エラーメッセージを表示するための要素（spanタグなど）を追加します。この要素にth:errors="*{フィールド名}"と記述することで、そのフィールドに関連付けられたエラーメッセージが存在する場合のみ、タグの内容がエラー文言に置換されて表示される仕組みを理解させます。また、th:if属性と#fieldsユーティリティオブジェクトを組み合わせて、エラーの有無を判定する手法についても触れます。
次に、エラーが発生した入力フィールド自体を目立たせるためのUI制御として、th:errorclass属性の利用法を学びます。この属性を使用すると、該当フィールドにエラーがある場合のみ、指定したCSSクラス（例えば、枠線を赤くするクラスなど）を動的に適用することができます。これにより、ユーザーは直感的に修正すべき箇所を認識できるようになります。
最後に、実装した一連のバリデーション機能の動作確認を行います。アプリケーションを起動し、ブラウザから意図的に空のタイトルや制限文字数を超えたデータを送信してみます。その結果、データベースへの登録が阻止され、画面に入力内容が保持されたまま戻り、適切なエラーメッセージとスタイルが適用されていることを確認します。また、正しいデータを入力した場合には正常に登録・更新ができることも併せて確認し、機能追加による回帰（既存機能の破壊）がないことも検証します。これらを通じて、フロントエンドとバックエンドが連携したバリデーションの全体像を把握させます。この細目で理解すべき範囲は、Thymeleafを用いたエラーメッセージの表示、動的なスタイル適用、およびアプリケーション全体の動作検証まで。
|
|
キーワード
|
① Bean Validation ② @Validated ③ BindingResult ④ th:errors ⑤ th:errorclass
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で実装した入力チェック機能の流れを再確認してください。特に、Formクラスでのアノテーション定義から、Controllerでの検証実行とBindingResultによる結果判定、そしてViewでのThymeleafを使ったエラー表示までの一連のデータの動きと制御フローを整理し、各要素がどのように連携しているかを頭の中でシミュレーションできるようにしてください。
◆次回授業の予習
次回はアプリケーション全体の結合テストとデバッグについて学びます。Webアプリケーション開発において、バグを特定し修正する作業は避けて通れません。一般的なソフトウェアテストの目的や種類について調べ、開発した機能が正しく動作することをどのように保証するか、またエラーが発生した際にどのように原因を調査するかについて、一般的な概念を整理しておいてください。
|
|
39
|
アプリの結合テストとデバッグ
|
科目の中での位置付け
|
本講義は、第6部「実践アプリケーション開発」の最終回に位置し、これまで構築してきたToDo管理アプリケーションの総仕上げを行う重要な回です。個別に実装してきた機能（一覧表示、登録、更新、削除、入力チェック）が、一つのシステムとして有機的に連携し、正しく動作するかを検証します。また、開発プロセスで避けて通れないバグの発見と修正手法を習得することで、実践的な開発能力を完成させ、次部のセキュリティ実装へと接続します。
|
|
|
コマ主題細目
|
① アプリケーション全体の統合的な動作検証 ② エラーログの解析とデバッグ手法の実践 ③ レイヤ化アーキテクチャと実装コードの総括
|
|
細目レベル
|
① 本細目では、これまでの講義で段階的に実装してきたToDo管理アプリケーションの各機能が、一つの統合されたシステムとして正しく連携し動作することを確認する「結合テスト」のプロセスを実践します。これまでは、特定の機能（例えば新規登録機能のみ）の実装直後にその機能単体の動作確認を行ってきました。しかし、実際のアプリケーション開発においては、個々の機能が正しく動作するだけでなく、それらが組み合わさった一連の業務フロー（シナリオ）において、データの不整合や画面遷移の不具合が発生しないことを保証する必要があります。まず、学生にはユーザーの視点に立ったシナリオテストを実施させます。具体的には、「トップページから新規登録画面へ遷移し、バリデーションエラーを確認した後に正しいデータを登録し、一覧画面で登録結果を確認する。その後、詳細画面へ遷移して内容を確認し、編集画面でデータを更新した後、最終的にそのデータを削除する」というCRUD（Create, Read, Update, Delete）の全工程を含む一連の操作を行います。
この検証過程において、特に注意すべき確認ポイントを詳細に指導します。例えば、新規登録や更新時にバリデーションエラーが発生した際、入力画面に戻ったときに入力済みの値が保持されているか、エラーメッセージが適切な位置に表示されているかを確認させます。また、登録や更新、削除が完了した後に、適切な画面（通常は一覧画面）へリダイレクトされているか、ブラウザの更新ボタンを押した際に二重送信の問題が発生しないような作りになっているか（PRGパターン：Post-Redirect-Getが機能しているか）といった、Webアプリケーション特有の挙動についても確認を促します。さらに、アプリケーションの画面上の確認だけでなく、データベース管理ツールであるpgAdminを使用して、バックエンドのデータベース（PostgreSQL）の状態を直接確認することも重要です。画面上ではデータが削除されたように見えても、データベース上では削除されていないといった不整合がないか、データのコミットが正しく行われているかを検証させます。このように、表層的な画面の動きだけでなく、裏側のデータ処理まで含めた完全な動作確認を行うことで、システムの品質を担保する姿勢を養います。この細目で理解すべき範囲は、シナリオに基づく全機能の動作確認とデータの整合性検証まで。
|
② 本細目では、アプリケーション開発において避けて通ることのできない「バグ」や「エラー」に直面した際の対処方法、すなわちデバッグの手法について体系的に解説し、実践します。初学者の多くは、エラー画面が表示されたり、想定通りの動作をしなかったりした際に、どのように原因を特定すればよいか戸惑う傾向にあります。そこで、まずはWebアプリケーション開発で頻繁に遭遇するエラーの種類と、それらが示す意味を理解させることから始めます。具体的には、HTTPステータスコードの意味を正しく解釈能力を養います。例えば、「404 Not Found」が発生した場合は、URLの入力ミスやControllerにおけるマッピング設定（@GetMappingや@PostMappingのパス）の誤り、あるいはHTMLテンプレートファイルの配置場所や名前の誤りである可能性が高いことを示唆します。また、「500 Internal Server Error」が発生した場合は、Javaプログラムの内部で例外（Exception）が発生していることを意味し、その原因はNullPointerExceptionやSQLの記述ミス、データベース接続エラーなど多岐にわたることを説明します。
次に、これらの原因を特定するための最も重要なツールである、統合開発環境（Eclipse）の「コンソールログ」の読み方について詳説します。Spring Bootアプリケーションが起動中に、またはリクエスト処理中にエラーが発生すると、コンソールには膨大な量のスタックトレース（エラーの履歴情報）が出力されます。この一見難解な情報の羅列から、重要な手がかりを見つけ出す方法を指導します。具体的には、スタックトレースを上から順に読むのではなく、「Caused by（～によって引き起こされた）」という記述を探し出し、そこに含まれる例外クラス名とメッセージ、そして何より自分自身が作成したクラス（パッケージ名がcom.example...などで始まるもの）の行番号を特定する手順を実践させます。これにより、エラーの発生箇所をピンポイントで特定し、ソースコードの該当部分を修正する能力を身につけさせます。また、入力フォームのname属性とFormクラスのフィールド名が一致していないためにデータが渡らないといった、エラーログに出にくい論理的なミスの発見方法についても触れ、仮説と検証を繰り返すデバッグのプロセスを体験させます。この細目で理解すべき範囲は、エラーログからの原因特定と修正作業の完了まで。
|
③ 本細目では、完成したToDo管理アプリケーションのソースコード全体を俯瞰し、本講義の前半から中盤にかけて学習してきたSpring Frameworkの核心的な概念やアーキテクチャが、実際のコードとしてどのように具現化されているかを総括します。まず、アプリケーションが「アプリケーション層（Controller）」「ドメイン層（Service）」「インフラストラクチャ層（Repository）」の3層構造（レイヤ化アーキテクチャ）に基づいて構成されていることを再確認します。各クラスがそれぞれの責務（Controllerはリクエストの受付と画面遷移、Serviceはビジネスロジックとトランザクション管理、Repositoryはデータベースアクセス）を適切に分担しているか、そしてそれらがインターフェースを介して疎結合に保たれているかを確認させます。これにより、なぜコードを分割して記述する必要があったのか、そのメリットである保守性や再利用性について理解を深めさせます。
また、DI（依存性の注入）の仕組みがコード内でどのように働いているかを振り返ります。@Autowiredアノテーションやコンストラクタインジェクションによって、各クラスがnewキーワードを使って依存オブジェクトを自分で生成することなく、SpringのDIコンテナからインスタンスの提供を受けている様子を確認します。さらに、データがクライアント（ブラウザ）から送信され、ControllerでFormクラスとして受け取られ、Service層でEntityクラスに変換されて処理され、最終的にRepositoryを通じてデータベースに保存されるという「データの流れ（Data Flow）」を追跡します。逆に、データベースから取得したデータがModelを通じてThymeleafのViewテンプレートに渡され、HTMLとしてレンダリングされる仕組みについても確認します。ここで、Lombokのアノテーション（@Dataなど）がいかに冗長なコード（getter/setterなど）を削減し、開発効率を高めていたかについても触れます。最後に、機能的には完成したものの、現時点では誰でもデータにアクセスできてしまう状態であることを指摘し、次部で学ぶ「Spring Security」による認証・認可機能の必要性を認識させることで、学習のモチベーションを次なるステップへと繋げます。この細目で理解すべき範囲は、アプリケーション全体の構造と各コンポーネントの役割の理解まで。
|
|
キーワード
|
① 結合テスト ② デバッグ ③ スタックトレース ④ HTTPステータスコード ⑤ レイヤ化アーキテクチャ
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回実施した結合テストの手順を振り返り、自分自身で作成したアプリケーションに対して、改めて一通りの操作を行ってみてください。特に、授業中に発生したエラーや、想定外の挙動があった場合は、その原因が何であったか、どのように修正したかをノートに整理してください。また、Eclipseのコンソールに出力されるログ情報を再度確認し、正常に動作している時のログと、エラー発生時のログの違いを見比べて、ログを読むことに慣れておいてください。
◆次回授業の予習
次回からは、Webアプリケーションにおけるセキュリティについて学習します。一般的なWebサイトにおいて、ログイン機能がなぜ必要なのか、ログインIDやパスワードがどのように管理されているかについて、普段利用しているサービスを例に考えてみてください。また、これまでの授業で作成したToDoアプリには、現在セキュリティ機能（ログインなど）が存在しないため、どのようなリスクが考えられるか、自分なりに想像して問題点を洗い出しておいてください。
|
|
40
|
Spring Securityの概要と導入
|
科目の中での位置付け
|
本講義は、全7部構成の最終章である第7部「セキュリティと総括」の初回に位置し、Webアプリケーション開発において不可欠な非機能要件である「セキュリティ」の実装に着手する重要な回である。これまでに構築したToDo管理アプリケーションに対し、業界標準のセキュリティフレームワークであるSpring Securityを導入することで、認証や認可といった堅牢なアクセス制御機能を付加する。単なる機能実装にとどまらず、Webシステムにおけるセキュリティの理論的背景とフレームワークによる解決策を体系的に理解し、実用レベルのアプリケーションへと昇華させるための第一歩としての位置づけにある。
|
|
|
コマ主題細目
|
① Webアプリケーションセキュリティの基礎概念と準備 ② Spring Securityの導入とデフォルト挙動の検証 ③ セキュリティ設定の仕組みとカスタマイズの概要
|
|
細目レベル
|
① 本細目では、Webアプリケーションを公開・運用する上で避けて通れないセキュリティの基礎概念について、学術的な視点から詳細に解説する。まず、情報セキュリティにおける最も基本的な概念である「認証（Authentication）」と「認可（Authorization）」の定義とその違いについて、学生に明確に理解させる。認証とは「通信相手が誰であるかを確認すること」であり、具体的にはユーザーIDとパスワード等を用いて本人確認を行うプロセスを指す。一方、認可とは「特定のリソースや機能へのアクセス権限を与えること」であり、認証されたユーザーに対して何を許可するかを制御するプロセスであることを対比させて説明する。これらは混同されやすい概念であるが、システム設計においては明確に区別して実装する必要があることを強調する。
続いて、これらのセキュリティ機能を自前で実装することのリスク（脆弱性の作り込みなど）を指摘し、フレームワークを利用する利点について解説する。ここで、Java開発におけるデファクトスタンダードである「Spring Security」の概要を紹介する。Spring Securityが、認証・認可のみならず、CSRF（クロスサイトリクエストフォージェリ）やセッションハイジャックといった一般的なWeb攻撃に対する防御機能を包括的に提供する強力なフレームワークであることを説明する。
また、講義の後半では、次項以降の実習に向けた準備として、認証後の遷移先となるメニュー画面の作成を行う。これまでのToDoアプリ開発では、トップページや一覧画面が直接のエントリーポイントとなっていたが、認証機能を導入するにあたり、ログイン成功後にユーザーが最初に目にするポータル的な役割を持つ画面が必要となる。`menu.html`および対応するコントローラの作成手順を指導し、ViewとControllerの基本的な連携を確認させる。この準備作業を通じて、セキュリティ導入前のアプリケーションの状態を整理し、導入後の変化を比較するためのベースラインを確立する。
この細目で理解すべき範囲は、認証と認可の概念的相違から、Spring Securityの役割、および実習環境の準備としてのメニュー画面実装まで。
|
② 本細目では、実際にプロジェクトに対してSpring Securityを導入し、その直後にアプリケーションの挙動がどのように変化するかを実践的に検証する。まず、ビルドツールであるGradleの設定ファイル（`build.gradle`）に、Spring Securityのスターター依存関係（`spring-boot-starter-security`）を追加する手順を解説する。この操作により、必要なライブラリ群がプロジェクトにダウンロードされ、クラスパスに追加される仕組みを復習する。
重要な学習ポイントは、依存関係を追加しただけで、Spring Bootの「Auto Configuration（自動設定）」機能によって強力なセキュリティ機能が即座に有効化される点である。アプリケーションを再起動し、これまで認証なしでアクセスできていたToDo一覧画面や新規登録画面などのすべてのURLに対してブラウザからアクセスを試みる演習を行う。この際、自動的にログイン画面（`/login`）へとリダイレクトされる挙動を確認し、Spring Securityが「Secure by Default（デフォルトで安全）」という設計思想に基づき、明示的な設定がない限りすべてのリソースを保護対象とすることを理解させる。
次に、デフォルトで提供される認証機能を用いたログイン操作を実践する。アプリケーション起動時のコンソールログに出力される、ランダム生成されたセキュリティパスワードを確認する方法を指導する。デフォルトのユーザー名である「user」と、ログから取得したパスワードを用いてログイン画面に入力し、認証に成功すると元のリクエスト先やルートパスへ遷移できることを体験させる。また、ブラウザの開発者ツール等を用いて、認証成功後に発行されるセッションID（JSESSIONID）やクッキーの存在を確認し、HTTPというステートレスなプロトコル上でどのようにログイン状態（セッション）が維持されているか、その技術的な裏側についても言及する。さらに、ログアウト処理についても触れ、セッションの無効化による認証状態の解除を確認する。
この細目で理解すべき範囲は、依存関係の追加によるフレームワークの導入から、自動設定によるデフォルトのアクセス制御とログイン画面の挙動確認まで。
|
③ 本細目では、デフォルトの挙動から一歩進んで、アプリケーションの要件に合わせたセキュリティ設定のカスタマイズ方法の概要について解説する。デフォルトの状態では、ユーザー名が固定であり、パスワードも起動ごとに変わるため、実用的なWebアプリケーションとしては不十分であることを認識させる。そこで、Spring Securityの設定をカスタマイズするために必要な構成クラス（Configuration Class）の作成方法を導入する。
具体的には、`@EnableWebSecurity`アノテーションを付与した設定クラスを作成し、その中で`SecurityFilterChain`をBean定義するという、Spring Securityの現代的な設定スタイルについて詳説する。この`SecurityFilterChain`が、HTTPリクエストを受け取ってからレスポンスを返すまでの過程で、一連のセキュリティフィルタ（認証フィルタ、認可フィルタ、CSRF対策フィルタなど）をどのような順序とルールで適用するかを決定する重要なコンポーネントであることを図解的に説明する。
設定クラスのひな型を作成し、`HttpSecurity`オブジェクトを用いて設定を記述する構造を学ぶ。ここでは詳細な実装までは行わないものの、特定のパス（例えば静的リソースやログイン画面自体）に対して認証を不要にする設定や、逆に特定のパスには厳格な認証を求める設定などが、このクラス内で集中的に管理されることを理解させる。また、認証方式（フォーム認証やBasic認証など）の選択や、ログインページのデザイン変更などもこの設定クラスを通じて行われることを示唆する。
この段階では、コードの細部よりも「設定クラスによってデフォルトの自動設定を上書き・拡張する」というSpring Bootにおける一般的なカスタマイズのパターンを理解することが重要である。これにより、次回の講義で扱う具体的な認証・認可の実装に向けた土台を形成する。最後に、設定クラスを導入したことによって、アプリケーションの起動や動作にエラーが生じていないかを確認し、環境が正しく構築されていることを検証する。
この細目で理解すべき範囲は、`SecurityFilterChain`を用いた設定クラスの役割と構造、およびセキュリティ設定のカスタマイズに向けた概念的な準備まで。
|
|
キーワード
|
① Spring Security ② 認証（Authentication） ③ 認可（Authorization） ④ HttpSecurity ⑤ SecurityFilterChain
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で学んだ「認証」と「認可」という二つの用語について、それぞれの定義と違いを自分の言葉で説明できるように整理してください。また、Spring Securityを依存関係に追加しただけで、Webアプリケーションの挙動が具体的にどう変化したか（リクエストの流れ、画面遷移、コンソールログの変化など）を振り返り、フレームワークが裏側で自動的に行っている処理について考察してください。
◆次回授業の予習
次回の授業では、Spring Securityの設定をさらに詳細にカスタマイズし、ログイン画面のデザイン変更や、ユーザーごとのアクセス制御（認可）の実装を行います。Webアプリケーションにおいて、一般ユーザーと管理者ユーザーでアクセスできる機能を分ける必要性について考え、一般的なWebサイトではどのような権限管理が行われているか、身近な例を想像して整理しておいてください。
|
|
41
|
認証・認可機能の実装とエラーハンドリング
|
科目の中での位置付け
|
本講義は、Webアプリケーション開発演習の最終段階に位置し、前回の授業で導入したSpring Securityの基礎知識を基盤として、より実践的かつ堅牢なセキュリティ機能を実装する重要な回である。これまで作成してきたToDoアプリケーションに対し、独自のログイン画面による認証機能のカスタマイズと、ユーザごとの適切な認可によるアクセス制御を組み込むことで、実運用に耐えうるアプリケーションへと昇華させる。また、エラー発生時の適切なユーザーインターフェースを提供するためのエラーハンドリング手法を習得し、ユーザビリティとセキュリティの両面からアプリケーションの品質を高めることを目的とする。
|
|
|
コマ主題細目
|
① Spring Securityのカスタマイズ設定と認証画面の実装 ② 認可の概念理解とアクセス制御の具体的実装 ③ アプリケーションの堅牢性を高めるエラーハンドリング
|
|
細目レベル
|
① 前回の授業で確認したSpring Securityのデフォルト設定では、フレームワークが提供する簡易的なログイン画面と自動生成されたパスワードを使用して動作確認を行ったが、実際のWebアプリケーション開発においては、アプリケーションのデザインや要件に合わせた独自の認証画面と認証プロセスが必要不可欠である。本主題では、Spring Securityの挙動をアプリケーションの仕様に合わせてカスタマイズする方法について詳説する。
まず、設定クラス（SecurityConfig）の役割と実装方法について解説する。Spring Bootにおいてセキュリティ設定をカスタマイズするためには、`@Configuration`および`@EnableWebSecurity`アノテーションを付与した設定クラスを作成し、その中で`SecurityFilterChain`をBean定義するという現代的なSpring Securityの実装スタイルを学生に理解させる。`HttpSecurity`オブジェクトを用いて、どのリクエストに対してセキュリティを適用するか、あるいは適用しないかを流暢なAPI（Fluent API）を用いて記述していく手法を学ぶ。
次に、独自のログイン画面への切り替え手順について実践的に解説する。デフォルトのログイン画面ではなく、Thymeleafを用いて作成したカスタムログイン画面を使用するために、`formLogin()`メソッドの設定詳細を掘り下げる。具体的には、`loginPage()`メソッドによるログイン画面のURLパス指定、`usernameParameter()`および`passwordParameter()`によるフォームの入力項目名とのマッピング、`defaultSuccessUrl()`によるログイン成功時の遷移先指定、そして`failureUrl()`によるログイン失敗時の遷移先指定といった一連の設定項目の意味と挙動を一つひとつ丁寧に解説し、学生に実装させる。
また、認証プロセスにおけるログアウト処理についても触れる。`logout()`メソッドを用いたログアウト機能の有効化、ログアウト実行時のセッション破棄（invalidateHttpSession）、Cookieの削除（deleteCookies）、およびログアウト成功後のリダイレクト先の設定について説明し、安全なセッション終了の仕組みを理解させる。これらの設定を通じて、ユーザーが違和感なく利用できる認証フローを構築する能力を養う。さらに、認証画面自体は未認証ユーザーでもアクセス可能でなければならないため、`permitAll()`メソッドを用いたアクセス許可設定の重要性についても論じ、セキュリティ設定における論理的な整合性の必要性を強調する。
この細目で理解すべき範囲は、SecurityFilterChainを用いたログイン画面の指定および認証・ログアウトプロセスのカスタマイズ設定まで。
|
② 認証（Authentication）によって「ユーザーが誰であるか」を特定した後は、そのユーザーが「何をしてよいか」を制御する認可（Authorization）のプロセスが重要となる。本主題では、認証と認可の概念的な違いを明確にした上で、Spring Securityを用いたアクセス制御の実装方法について詳説する。
まず、認証と認可の違いの二つの用語が混同されやすい点に注意を促しつつ、身近な事例（例えば、社員証による入館が認証、会議室への入室権限が認可など）を用いて概念を整理させる。その上で、Webアプリケーションにおける認可とは、具体的にURLやリソースに対するアクセス権限の管理であることを理解させる。
次に、`SecurityFilterChain`内での認可設定の実装について解説する。`authorizeHttpRequests()`メソッドと`requestMatchers()`メソッドを組み合わせることで、特定のURLパスに対してどのようなアクセス制限を設けるかを定義する手法を学ぶ。例えば、静的リソース（CSS、JavaScript、画像ファイルなど）やログイン画面、ユーザー登録画面など、全てのユーザーに公開すべきリソースに対しては`permitAll()`を設定し、ToDo一覧画面や詳細画面など、ログイン済みユーザーのみにアクセスを許可すべきリソースに対しては`authenticated()`を設定するといった、具体的なアクセス制御ルールを記述する能力を涵養する。この際、設定の記述順序が重要であること（具体的なルールから一般的なルールへと記述する原則）についても触れ、設定ミスの防止につなげる。
さらに、依存関係の追加に関連して、画面表示レベルでの認可制御についても解説する。ThymeleafのSpring Security拡張機能（`thymeleaf-extras-springsecurity6`）をプロジェクトに導入することで、HTMLテンプレート内で認証状態やユーザー情報を参照できるようになることを説明する。これにより、ログイン済みの場合にのみログアウトボタンを表示したり、ログインユーザー名を表示したりするなど、ユーザーの権限状態に応じた動的な画面表示の切り替えが可能になることを実践を通じて理解させる。また、アクセス権限がないページにアクセスしようとした際に発生するHTTP 403 Forbiddenエラーの意味についても解説し、適切なアクセス制御がセキュリティリスクを低減させるメカニズムを学ばせる。
この細目で理解すべき範囲は、認証と認可の概念的区別およびURLベースのアクセス制御設定とThymeleafにおける認可情報の利用まで。
|
③ Webアプリケーションにおいて、予期せぬエラーやアクセス拒否が発生した際に、ユーザーに対して適切な情報を提示することは、ユーザビリティの観点のみならず、セキュリティの観点からも極めて重要である。本主題では、Spring BootおよびSpring Securityにおけるエラーハンドリングの仕組みと、カスタムエラーページの作成方法について詳説する。
まず、エラーページの重要性について講義する。システム内部のエラー情報（スタックトレースなど）がそのままブラウザに表示されることは、攻撃者にシステムの内部構造や脆弱性のヒントを与えることになりかねないため、セキュリティリスクとなることを理解させる。また、単なる白い画面や分かりにくい英語のエラーメッセージはユーザーの混乱を招き、アプリケーションへの信頼を損なう要因となるため、ユーザーフレンドリーなエラーページを用意することの意義を説明する。
次に、Spring Bootが提供するデフォルトのエラーハンドリング機能について解説する。Spring Bootでは、エラーが発生した場合に自動的に`/error`へのマッピングが行われ、Whitelabel Error Pageが表示される仕組みを持っている。このデフォルトの挙動を理解した上で、独自のHTMLテンプレートを用意することで、このエラーページをカスタマイズする方法を学ぶ。具体的には、`src/main/resources/templates/error/`ディレクトリ配下に、HTTPステータスコードに対応したファイル名（例えば`404.html`や`403.html`、あるいは汎用的な`error.html`）でHTMLファイルを作成・配置するだけで、自動的にカスタムエラーページが表示されるというSpring Bootの「設定より規約（Convention over Configuration）」の思想を体感させる。
特に、本講義の文脈で重要となるHTTPステータスコードとして、認証・認可に関連する「403 Forbidden（アクセス権限がない）」と、リソースが存在しない場合の「404 Not Found」、およびサーバー内部エラーの「500 Internal Server Error」を取り上げ、それぞれの発生原因とユーザーへの適切な案内方法について検討させる。実際にToDoアプリケーション用の統一感のあるデザインでエラーページを作成し、認証エラーや不正アクセス時にこれらのページが正しく表示されることを確認する演習を行う。これにより、例外的な状況においてもユーザーを適切に誘導し、アプリケーションの品質を維持する能力を養う。
この細目で理解すべき範囲は、カスタムエラーページの作成および配置によるHTTPステータスコードに応じたエラーハンドリングの実装まで。
|
|
キーワード
|
① 404 ② 403 ③ SecurityFilterChain ④ アクセス制御 ⑤ カスタムエラーページ
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で実装したセキュリティ設定クラスのコードを見直し、各メソッドがどのような役割を果たしているかを再確認すること。特に、認証の設定（ログイン画面の指定や遷移先の設定）と認可の設定（URLごとのアクセス制限）が、実際のアプリケーションの挙動とどのようにリンクしているかを、ブラウザでの操作を通じて確認し、理解を深めておくこと。また、エラーページが表示される条件を意図的に作り出し、実装したエラーハンドリングが正しく機能しているかを確認すること。
◆次回授業の予習
次回からは、これまでの講義全体の総復習に入るため、第1回から第41回までの学習内容を網羅的に振り返っておくこと。特に、Webアプリケーションの基礎構造、Spring Frameworkの主要機能（DI、AOP）、MVCモデル、データベース操作、そして今回のセキュリティ機能といった各要素が、一つのアプリケーションの中でどのように連携しているかを整理しておくこと。不明点や理解が曖昧な箇所があれば、これまでのテキストの該当章や配布資料を読み返し、質問事項をまとめておくこと。
|
|
42
|
総復習（前半1）
|
科目の中での位置付け
|
本講義は、全45回のコースにおける第42回目に位置し、第7部「セキュリティと総括」の第3回目にあたります。ここでは、第1部から第3部までに学習した、Webアプリケーション開発の歴史的背景、HTTPプロトコルの基礎、そしてSpring Frameworkの中核概念であるDI（依存性の注入）およびAOP（アスペクト指向プログラミング）について総復習を行います。これまでの演習を通じて得られた実践的な経験を、理論的な裏付けと再結合させ、フレームワークを利用する意義とその内部動作原理に対する理解を確固たるものにすることを目的とします。
|
|
|
コマ主題細目
|
① Web技術の変遷とServlet/JSPにおける開発課題の再確認 ② Spring Frameworkの導入意義とDI（依存性の注入）のメカニズム ③ AOP（アスペクト指向プログラミング）による横断的関心事の分離
|
|
細目レベル
|
① この主題では、第1部で学習したWebアプリケーション開発の歴史的変遷と、Java ServletおよびJSPを用いた開発実習を通じて浮き彫りになった課題について、改めて詳細に振り返ります。まず、インターネットの普及とともに静的なHTMLのみならず、ユーザーの入力や状態に応じて動的にコンテンツを生成する必要性が高まった背景を概観します。その解決策として登場したCGIから、よりパフォーマンスに優れたJava Servletへの進化の過程を解説し、HTTPプロトコルの基本特性であるステートレス性と、それを補うためのセッション管理の仕組み（HttpSession）について再確認します。授業の前半では、学生が実際に第3回から第6回にかけて記述したServletとJSPのコードを想起させながら、具体的な実装上の問題点を整理します。たとえば、Servletクラス内で`out.println`メソッドを使用してHTMLタグを文字列として出力することの煩雑さや可読性の低さ、あるいはJSPファイル内にJavaのロジック（スクリプトレット）が混在することによる保守性の低下について議論します。
さらに、Model 2アーキテクチャの導入によって、処理（Servlet）と表示（JSP）を分離する試みが行われたものの、依然として残る課題について深掘りします。具体的には、画面遷移やリクエストパラメータの取得、スコープへのデータ格納と取り出しといった定型的な処理（ボイラープレートコード）を毎回手動で記述しなければならない非効率性や、`web.xml`などの設定ファイル管理の煩雑さを指摘します。また、GETメソッドとPOSTメソッドの使い分けや、リクエストパラメータがすべて文字列として扱われるための型変換の手間など、フレームワークを使用しない「素のJava」での開発がいかに開発者に負担を強いるものであるかを強調します。これらの振り返りを通じて、なぜSpring Frameworkのような現代的なフレームワークが必要とされるのか、その動機付けを論理的に再構築します。学生には、フレームワークが単なる便利なツールではなく、先人たちが直面した構造的な課題を解決するために蓄積された「デザインパターンとベストプラクティス」の集合体であることを理解させます。この細目で理解すべき範囲は、Webアプリケーションの基本構造からServletとJSPを用いた開発における技術的・構造的な課題の特定まで。
|
② この主題では、第2部および第3部前半で扱ったSpring Frameworkの基礎概念、特にDI（Dependency Injection：依存性の注入）の原理と実装方法について詳説します。まず、「フレームワークとはアプリケーション開発の骨組みである」という定義に立ち返り、Springが提供する多岐にわたる機能群（Spring Boot, Spring MVC, Spring Dataなど）の全体像を俯瞰します。その上で、Springの中核（Core）機能であるDIコンテナの役割について解説を進めます。DIを理解するための前提知識として、Javaにおけるインターフェースとポリモーフィズムの重要性を復習します。クラス間の関係が「密結合」である状態、すなわち`new`キーワードを用いて具象クラスを直接インスタンス化することが、将来的な仕様変更や単体テストに対していかに脆弱であるかを、具体的なコード例（テキストの計算機や挨拶プログラムの例など）を用いて説明します。
次に、これらの問題を解決するための「疎結合」な設計と、それを実現するDIコンテナの仕組みについて解説します。Springにおいては、開発者が直接インスタンスを生成・管理するのではなく、DIコンテナがインスタンス（Bean）の生成、ライフサイクル管理、そして依存関係の解決（注入）を一手に引き受ける「制御の反転（IoC）」が行われていることを強調します。ここでは、`@Component`、`@Controller`、`@Service`、`@Repository`といったステレオタイプアノテーションの役割と、コンポーネントスキャンによってこれらが自動的に検出・登録されるプロセスを整理します。また、`@Autowired`アノテーションを用いたフィールドインジェクションやコンストラクタインジェクションの挙動を確認し、各レイヤ（アプリケーション層、ドメイン層、インフラストラクチャ層）がどのように連携するかをアーキテクチャの視点から解説します。これにより、学生は単にアノテーションを記述するだけでなく、その背後でDIコンテナがどのようにオブジェクトグラフを構築しているかをイメージできるようにします。この細目で理解すべき範囲は、インターフェースによる疎結合化の理論から、SpringのDIコンテナによるインスタンス管理と依存性注入の具体的な動作原理まで。
|
③ この主題では、第3部後半で学習したAOP（Aspect Oriented Programming：アスペクト指向プログラミング）の概念とその適用方法について総復習を行います。オブジェクト指向プログラミング（OOP）だけでは解決が困難な課題、すなわち「横断的関心事」の散在について解説することから始めます。ログ出力、例外処理、トランザクション管理といった機能は、アプリケーションの主要なビジネスロジック（中心的関心事）とは異なる性質を持ちながら、システムの至る所に重複して記述されがちです。これがコードの可読性を下げ、保守を困難にしている現状を指摘し、AOPがこれらの関心事をモジュール化して分離する技術であることを説明します。
授業では、AOPを構成する専門用語である「Aspect（アスペクト）」、「Advice（アドバイス）」、「Pointcut（ポイントカット）」、「JoinPoint（ジョインポイント）」、「Weaving（ウィービング）」について、それぞれの定義と関係性を明確にします。テキストの例を用いながら、Adviceが「何を・いつ」実行するか（メソッド実行前、実行後、例外発生時など）を定義し、Pointcutが「どこで」実行するか（特定のパッケージやメソッド名のパターン）を指定するものであることを再確認します。これにより、ビジネスロジックを変更することなく、宣言的に機能を追加できる仕組みを理解させます。
さらに、Spring FrameworkにおけるAOPの実践的な応用例として、データベース操作におけるトランザクション管理を取り上げます。`@Transactional`アノテーションを付与するだけで、メソッドの開始時にトランザクションが開始され、正常終了時にコミット、例外発生時にロールバックが行われるという複雑な処理が、AOPによっていかに透過的に実装されているかを解説します。これは第6部のToDoアプリ開発でも頻繁に使用した機能であり、その裏側にある技術的基盤を理解することは、トラブルシューティングや高度な設計を行う上で不可欠です。最後に、DIとAOPがSpring Frameworkの両輪として機能し、開発者がビジネスロジックの実装に集中できる環境を提供していることを総括します。この細目で理解すべき範囲は、AOPの基本概念と用語の定義から、Springにおける具体的な実装方法およびトランザクション管理への応用まで。
|
|
キーワード
|
① DI（依存性の注入） ② AOP（アスペクト指向プログラミング） ③ DIコンテナ ④ 疎結合 ⑤ 横断的関心事
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で扱った第1部から第3部までの講義資料および自身の作成した演習コードを見直してください。特に、Servlet/JSPで作成したログイン機能のコードと、Springを用いて作成したToDoアプリの構成を比較し、DIやAOPがどのようにコードの記述量を減らし、構造を整理しているかを具体的に確認してください。また、DIの概念図やAOPの用語（Advice, Pointcutなど）の意味を、何も見ずに説明できるか自己チェックを行うことを推奨します。
◆次回授業の予習
次回は第4部（Spring MVC/Thymeleaf）から第5部（データ検証/MyBatis）までの総復習を行います。MVCモデルにおけるリクエストの処理フローや、ControllerとView（Thymeleaf）間のデータの受け渡し方法（Model、Formクラス）、およびMyBatisを用いたデータベース操作の基本設定について、過去の資料やテキストの該当箇所に目を通し、記憶を喚起しておいてください。特にアノテーションの役割について整理しておくと、スムーズに理解が深まります。
|
|
43
|
総復習（前半2）
|
科目の中での位置付け
|
本講義は、全45回にわたるWebアプリケーション開発演習の第43回目に位置し、コース終盤における総復習の第2段階にあたります。前回確認したSpring Frameworkの基礎理論（DI/AOP）に続き、本回ではWebアプリケーションの実装における中核技術であるWeb表示層（Spring MVC/Thymeleaf）とデータ層（バリデーション/MyBatis）の連携に焦点を当てます。これらは第4部および第5部で扱った内容であり、ユーザーインターフェースからデータベースに至るまでの一連のデータフローを再構築し、次回のアプリケーション構築プロセスの総括へと接続するための重要な統合確認の場となります。
|
|
|
コマ主題細目
|
① Spring MVCとThymeleafによる画面生成 ② リクエスト処理と入力値の検証 ③ O/Rマッパーによるデータベース連携
|
|
細目レベル
|
① 本細目では、第4部で学習したSpring MVCのアーキテクチャとテンプレートエンジンThymeleafを用いた動的コンテンツの生成手法について、理論と実装の両面から詳細な再確認を行います。まず、MVC（Model-View-Controller）モデルの基本概念に立ち返り、Spring FrameworkがいかにしてHTTPリクエストを処理し、レスポンスを生成しているかという内部フローを体系的に整理します。具体的には、クライアントからの要求を受け取るDispatcherServletの役割から、適切なControllerへの振り分け、そしてビジネスロジックの実行結果をViewに渡すまでの一連の流れを概観します。
特に重点を置くのは、ControllerとViewの間でデータを受け渡すための「Model」インターフェースの役割です。`addAttribute`メソッドを用いてJavaのオブジェクトをModelに格納し、それをThymeleaf側でどのように取り出して表示するかというデータバインディングの仕組みを詳説します。ここでは、単なる文字列の表示だけでなく、`th:each`を用いたリスト構造の反復処理や、`th:if`による条件分岐など、動的なHTML生成に不可欠な制御構文の復習も行います。これらは、静的なHTMLファイルとは異なり、サーバーサイドの状態に応じて画面の表示内容を変化させるWebアプリケーションの本質的な機能です。
また、画面レイアウトの共通化（フラグメント化）についても触れ、ヘッダーやフッターなどの共通部品を効率的に管理する手法を再確認します。これにより、保守性の高いフロントエンド実装の在り方を学生に理解させます。授業の進行としては、具体的なコード例を用いつつ、Controllerのアノテーション記述からThymeleafのテンプレート記述までの整合性を確認する形式をとり、各要素がどのように連携して一つのWebページを構成しているかを論理的に結び付けます。これらを通じて、サーバーサイドJavaとフロントエンド技術の接点における実装能力を盤石なものとします。
この細目で理解すべき範囲は、MVCモデルに基づくリクエスト処理フローの理解から、Thymeleafを用いた動的な画面生成とレイアウト管理の実装手法まで。
|
② 本細目では、Webアプリケーションにおけるユーザー入力の取り扱いについて、データの受信からバリデーション（妥当性確認）までのプロセスを詳細に復習します。これは堅牢なアプリケーションを構築するために不可欠な要素です。まず、クライアントから送信されるHTTPリクエスト（GET/POST）に含まれるデータを、サーバーサイドのJavaプログラムでどのように受け取るかという点について解説します。具体的には、`@RequestParam`を用いた個別のパラメータ取得と、Formクラス（DTO）を用いたオブジェクトへの一括バインディングの違いと使い分けについて整理します。特に、入力項目が多いWebフォームにおいて、Formクラスを利用することがデータの管理や可読性の向上にいかに寄与するかを、実際のコード構造と比較しながら論じます。
次に、受け取ったデータの整合性を保証するためのバリデーション機能について詳説します。Spring FrameworkにおけるBean Validationの仕組みを利用し、`@NotNull`、`@Size`、`@Min`などのアノテーションをFormクラスのフィールドに付与することで、宣言的に入力チェックルールを定義できる利点を再確認します。ここでは、単項目チェックだけでなく、複数の項目にまたがる相関チェックの実装パターンについても触れ、複雑なビジネスルールへの対応方法を復習します。
さらに重要な点として、バリデーション結果のハンドリング方法について解説します。`BindingResult`インターフェースを用いてエラー情報を捕捉し、エラーが存在する場合に処理を中断して入力画面に差し戻すフロー制御や、Thymeleaf側でのエラーメッセージの表示方法（`th:errors`）について実践的な視点で確認します。これにより、不正なデータがデータベースや後続の処理に流れることを防ぐための防衛的プログラミングの重要性を学生に認識させます。授業では、意図的に不正なデータを送信した場合の挙動をシミュレーションし、適切なエラーハンドリングが行われているかを確認する視点を養います。
この細目で理解すべき範囲は、リクエストパラメータのFormクラスへのバインディングから、アノテーションを用いた入力チェックおよびエラーハンドリングの実装まで。
|
③ 本細目では、データ永続化層の実装技術であるO/Rマッパー（MyBatis）について、その概念と具体的な利用方法を総括します。Webアプリケーションにおいて、Javaのオブジェクト指向モデルとリレーショナルデータベースのテーブル構造との間には「インピーダンスミスマッチ」と呼ばれるギャップが存在します。本講義では、この課題を解決するためのツールとしてのO/Rマッパーの役割を再定義し、JDBCを直接利用する場合と比較して、開発効率や保守性がどのように向上するかを理論的に解説します。
具体的には、Spring FrameworkにおけるMyBatisの導入方法から、MapperインターフェースとXMLマッパーファイル（またはアノテーション）を用いたSQLの管理方法について詳細に復習します。Javaのメソッド呼び出しがどのようにしてSQLの実行に変換され、その結果がどのようにJavaオブジェクト（Entity）にマッピングされるかという内部メカニズムを、図解を交えて整理します。ここでは、単純なCRUD（作成、参照、更新、削除）操作の実装だけでなく、検索条件の指定や、`ResultMap`を用いたデータベースのカラム名とJavaフィールド名のマッピング設定など、実務で頻出するパターンについても触れます。
また、第1部で学習したServlet/JSP時代の手動によるConnection管理やPreparedStatementの記述と比較し、DIコンテナによって管理される`DataSource`やトランザクション管理の恩恵についても言及します。Spring Bootが提供する自動設定により、データベース接続設定がいかに簡略化されているかを再確認し、現代的な開発環境におけるインフラストラクチャ層の抽象化のメリットを深く理解させます。授業の進行としては、ControllerからServiceを経由してMapper（Repository）が呼び出され、データベースから取得したデータが再びControllerに戻るまでの完全なラウンドトリップを確認し、Web層とデータ層の統合的な理解を促します。これにより、永続化層を含むフルスタックなWebアプリケーション開発の基礎を確固たるものにします。
この細目で理解すべき範囲は、O/Rマッパーの基本概念の理解から、MyBatisを用いたMapper定義およびSQL実行によるデータベース操作の実装まで。
|
|
キーワード
|
① MVCモデル ② Thymeleaf ③ データバインディング ④ Bean Validation ⑤ O/Rマッパー
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で扱ったSpring MVCによる画面遷移、Thymeleafによる動的表示、Formクラスを用いた入力値の受け取りとバリデーション、そしてMyBatisによるデータベース操作という一連の流れについて、それぞれの要素がどのように連携していたかを頭の中で整理してください。特に、Controllerが司令塔となり、ViewとModel、そしてRepository（Mapper）をつなぐハブとして機能している構造を、図を描いて再確認することを推奨します。各層のアノテーションの役割を再確認し、データが流れる経路を明確にイメージできるようにしてください。
◆次回授業の予習
次回の授業では、第6部で実施した「ToDoアプリケーション開発」のプロセス全体を振り返り、実践的なアプリケーション構築の流れを総復習します。これまでに作成したToDoアプリのソースコード全体を見直し、特にController、Service、Repositoryの各レイヤがどのように責務を分担しているかを確認しておいてください。また、単なる機能実装だけでなく、アプリケーションの設計思想やディレクトリ構成がどのようになっていたかを思い出しておくと、次回の講義内容をより深く理解し、自身の知識として定着させることができます。
|
|
44
|
総復習（後半1）
|
科目の中での位置付け
|
本講義は、全45回にわたるWebアプリケーション開発演習の第44回目であり、第6部で実施した「ToDo管理アプリケーション」の構築プロセス全体を俯瞰し、体系的に整理する重要な位置付けにあります。ここでは、個別の実装技術だけでなく、レイヤ化アーキテクチャに基づく設計思想や、データフローの全体像、およびアプリケーションの品質を支える検証機能について再確認し、実践的な応用力を定着させることを目的とします。
|
|
|
コマ主題細目
|
① アプリケーション設計とレイヤ化アーキテクチャの再整理 ② ToDoアプリにおけるCRUD処理の実装プロセスとデータフロー ③ アプリケーションの品質向上と堅牢性の確保
|
|
細目レベル
|
① 本講義の最初の主題として、第6部で構築したToDoアプリケーションの設計基盤となる「レイヤ化アーキテクチャ」について、その構造と各コンポーネントの役割を詳細に再整理します。Spring Frameworkを用いた開発において、ソースコードを適切な役割ごとに分割・整理することは、保守性や拡張性を高める上で極めて重要です。テキストで採用されているアーキテクチャは、ユーザーインターフェースを担当する「アプリケーション層」、ビジネスロジックの中核を担う「ドメイン層」、そしてデータの永続化や外部連携を担当する「インフラストラクチャ層」の3層構造に基づいています。まず、アプリケーション層におけるControllerの役割について確認します。ControllerはクライアントからのHTTPリクエストを受け取り、適切なレスポンスを返すための窓口として機能しますが、ここに複雑な業務ロジックを記述すべきではありません。次に、ドメイン層におけるServiceの役割を詳説します。Serviceは、アプリケーションが提供する機能（ユースケース）を表現する場所であり、トランザクション境界の設定や、複数のRepositoryを組み合わせた処理の制御を行います。そして、インフラストラクチャ層におけるRepositoryとMapperの役割について解説します。これらはデータベースとの具体的な対話を担当し、SQLの発行や結果のマッピングを行いますが、ビジネスロジックを含めないことが原則です。さらに、これらの各層を行き来するデータオブジェクトとして、データベースのテーブル構造を反映したEntity（Domain Object）と、画面入力に特化したFormクラスの使い分けについても言及します。特に、入力フォームのデータ構造とデータベースの永続化データ構造が必ずしも一致しない場合、これらを明確に分離することの重要性を再認識させます。また、これらのコンポーネントがSpringのDIコンテナによってどのように管理され、@Controller、@Service、@Repositoryといったアノテーションを通じてどのように依存性が注入されるかというメカニズムについても復習します。このレイヤ化の概念を正しく理解することで、大規模な開発においても秩序あるコードベースを維持できる能力を養います。この細目で理解すべき範囲は、レイヤ化アーキテクチャの各層の責務定義から、DIを利用したコンポーネント間の連携構造、およびEntityとFormクラスの役割分担の理解まで。
|
② 二つ目の主題では、Webアプリケーションの基本機能であるCRUD（Create, Read, Update, Delete）処理の実装プロセスを通じて、リクエストからレスポンスに至るまでの詳細なデータフローを統合的に理解します。ここでは、ToDoアプリケーションの具体的な機能を例に挙げながら、各処理がどのように連携して動作しているかを追跡します。まず、参照（Read）機能について、ControllerがServiceを呼び出し、ServiceがRepository経由でデータベースからデータを取得し、その結果をModelに格納してThymeleafテンプレートに渡すまでの一連の流れを復習します。ここでは、MyBatisのMapperインターフェースとXMLファイルにおけるSQL記述の対応関係や、ResultMapを用いたオブジェクトマッピングの仕組みについても再確認します。次に、新規登録（Create）および更新（Update）機能におけるデータの流れを詳説します。入力画面の表示（GETリクエスト）から、フォームデータの送信（POSTリクエスト）、そしてデータの保存処理完了後のリダイレクトという一連のプロセス（PRGパターン：Post-Redirect-Get）の重要性を解説します。特に、Formクラスを用いたリクエストパラメータのバインディング機構や、Controllerのメソッド引数における@ModelAttributeの役割について深く掘り下げます。更新処理においては、既存データの取得から画面への初期表示、そして変更内容の反映というステップが必要であり、主キー（ID）の取り扱いやHiddenフィールドの利用といった実装上のポイントを整理します。削除（Delete）機能についても同様に、対象データの特定から削除実行、そして一覧画面への遷移というフローを確認します。これらの処理を通じて、HTTPメソッド（GET/POST）の適切な使い分けや、URLパス変数（@PathVariable）とリクエストパラメータ（@RequestParam）の違いなど、Web通信の基礎技術がどのように応用されているかを体系的に理解させます。また、各レイヤ間でデータが受け渡される際に、どのオブジェクト（EntityまたはForm）が使用されるべきかというデータ変換の観点についても整理し、実践的な実装能力を確実なものにします。この細目で理解すべき範囲は、CRUD各機能におけるリクエスト受信からDB操作、画面遷移に至るまでの完全なデータフローと、それを実現するためのSpring MVCおよびMyBatisの実装パターンの理解まで。
|
③ 最後の主題として、作成したアプリケーションが実運用に耐えうる品質を持つために不可欠な「バリデーション（入力検証）」と「トランザクション管理」について詳説し、堅牢なシステム構築のための手法を総括します。Webアプリケーションにおいて、ユーザーからの入力値を無条件に信頼することはセキュリティやデータ整合性の観点から危険であり、適切な検証が必要です。ここでは、Bean Validation（JSR 380）に基づいたアノテーション（@NotEmpty, @Size, @Minなど）をFormクラスに付与し、宣言的に入力チェックを行う手法を復習します。Controller層において、@Validatedアノテーションを用いて検証を実行し、その結果をBindingResultインターフェースで受け取るメカニズムについて解説します。入力エラーが発生した場合に、処理を中断して入力画面に戻し、適切なエラーメッセージをThymeleaf側で表示するまでの一連の実装フローを確認します。また、単項目チェックだけでなく、相関項目チェックや独自バリデーションの必要性についても触れ、要件に応じた検証ロジックの組み込み方を整理します。次に、データの整合性を保つためのトランザクション管理について解説します。特に、データベースへの更新処理を伴うServiceメソッドにおいて、@Transactionalアノテーションを付与することで、Spring Frameworkがどのようにトランザクション境界を制御しているかを理解させます。処理が正常に完了した場合にはコミットされ、実行時例外（RuntimeException）が発生した場合には自動的にロールバックされる仕組みは、データの不整合を防ぐ上で極めて重要です。ToDoアプリの開発プロセスを振り返り、これらの機能が単なる付加機能ではなく、業務アプリケーションとして成立するための必須要件であることを強調します。さらに、開発中に発生したバグの特定や修正（デバッグ）の経験を通じて得られた知見も踏まえ、エラーハンドリングを含めた総合的な品質確保の考え方を定着させます。この細目で理解すべき範囲は、Bean Validationを用いた入力検証の実装手法から、エラーハンドリング、および@Transactionalによる宣言的トランザクション管理を用いたデータ整合性の確保手法の理解まで。
|
|
キーワード
|
① レイヤ化アーキテクチャ ② CRUD処理 ③ Formクラス ④ Bean Validation ⑤ トランザクション管理
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で総括したToDoアプリケーションの設計と実装について、自身の作成したソースコードを改めて読み返し、各クラスがどのレイヤに属し、どのような責務を果たしているかを確認してください。特に、ControllerからService、Repositoryへと処理が委譲される流れや、FormクラスとEntityクラスのデータ変換が行われている箇所を重点的に追跡し、データの流れを頭の中でシミュレーションできるようにしてください。また、バリデーションのアノテーションやトランザクションの設定が正しく機能している理由を、講義内容と照らし合わせて再確認してください。
◆次回授業の予習
次回の授業では、Webアプリケーション開発の総仕上げとして、セキュリティ機能の実装と講義全体の総括を行います。これに備えて、Webアプリケーションにおける一般的なセキュリティリスクや、認証（Authentication）と認可（Authorization）の違いについて、これまでの学習内容や一般的なWebの知識を用いて整理しておいてください。また、ToDoアプリに対してログイン機能を追加する場合、どのようなテーブル設計や画面遷移が必要になるか、自分なりに想像してみることで、次回の講義内容をスムーズに理解する準備を整えてください。
|
|
45
|
総復習（後半2）
|
科目の中での位置付け
|
本講義は、全45回にわたるWebアプリケーション開発演習の最終回である。ここでは、前回扱いきれなかったセキュリティ機能（Spring Security）の詳細、特にエラーハンドリングとユーザビリティの観点からの実装を完結させる。その上で、半期間を通じて学習したSpring Frameworkの全体像（DI、AOP、MVC、データアクセス、セキュリティ）を統合的に振り返り、各技術要素がどのように連携して堅牢なシステムを構築しているかを再確認する。学生が本講義で得た知識を体系化し、今後の自律的な学習や実務への応用につなげるための重要な総仕上げの場と位置付けられる。
|
|
|
コマ主題細目
|
① Spring Securityによる認証・認可の概念と実装 ② セキュリティとユーザビリティを考慮したエラーハンドリング ③ Spring FrameworkによるWeb開発の総括と今後の展望
|
|
細目レベル
|
① 本講義の締めくくりとして、Webアプリケーションにおけるセキュリティの要である「認証（Authentication）」と「認可（Authorization）」の概念的相違と、Spring Securityを用いた実装方法について詳説する。まず、認証が「通信相手が誰であるか（本人確認）」を特定するプロセスであるのに対し、認可は「特定された相手に何をする権限を与えるか（アクセス制御）」を決定するプロセスであることを明確に区別し、学生に理解させる。Webアプリケーション開発において、これらをスクラッチで実装することは極めて難易度が高く、セキュリティホールの原因となりやすい。そこで、Spring Securityというフレームワークを利用することで、これらの機能を「横断的関心事」としてアプリケーション本体のロジックから分離し、宣言的に適用可能であることを解説する。
授業では、まずSpring Initializrを用いて依存関係を追加するだけで、デフォルトのログイン画面や認証機能が自動的に有効化される仕組みを実演し、フレームワークの強力な支援機能を体感させる。その上で、実務的な要件に合わせてログイン画面をカスタマイズする方法や、特定のURLパターン（例えば管理者用ページなど）に対してアクセス制限（認可）を設定する手順を解説する。ここでは、設定クラス（SecurityConfigなど）における記述方法や、Thymeleafと連携してログイン状態に応じた画面表示の切り替え（ログイン中のみログアウトボタンを表示するなど）を行う手法についても触れる。また、認証と認可が正しく機能しない場合のリスクについても言及し、パスワードのハッシュ化やCSRF対策など、Spring Securityが裏側で提供している安全対策についても概観することで、フレームワークを利用する意義を深く認識させる。最終的に、ToDoアプリに対してログイン認証を組み込み、登録されたユーザのみが自身のToDoを管理できる状態までを実装の流れとして整理する。この細目で理解すべき範囲は、Spring Securityの導入から認証・認可の基本設定、およびこれらがWebアプリケーションの安全性にどのように寄与するかを理解するまで。
|
② Webアプリケーションの品質を決定づける重要な要素として、予期せぬ事態や不正なアクセスが発生した際のエラーハンドリングについて詳説する。システム内部のエラー情報（スタックトレースなど）がそのまま利用者のブラウザに表示されることが、セキュリティ上の脆弱性（情報漏洩）につながるリスクを指摘する。同時に、単なる白い画面や難解な英文のエラーメッセージが表示されることは、ユーザビリティ（UX）の観点からも極めて不適切であることを説明する。これらを解決するために、Spring Bootが提供するカスタムエラーページの仕組みを導入し、適切なエラーハンドリングを実装する手法を解説する。
具体的には、HTTPステータスコード（404 Not Found、403 Forbidden、500 Internal Server Errorなど）に対応したHTMLファイルを所定のディレクトリ（templates/error/）に配置するだけで、フレームワークが自動的に適切なビューを選択して表示する仕組みを学ぶ。特に、Spring Security導入後は、認証されていないユーザが保護されたリソースにアクセスしようとした場合や、権限のない操作を行おうとした場合に「403 Forbidden」が発生する頻度が高まるため、これに対する親切な案内画面（「権限がありません」「ログインしてください」等のメッセージ表示）を作成することの重要性を強調する。
授業では、実際にわざと存在しないURLにアクセスしたり、権限のないページへ遷移を試みたりすることでエラーを発生させ、デフォルトのエラーページ（Whitelabel Error Page）と、自身で作成したカスタムエラーページの違いを比較検証する。また、Thymeleafを用いてエラーページ内にも共通レイアウト（ヘッダーやフッター）を適用し、サイト全体の統一感を損なわずにエラー情報を伝える実装テクニックについても触れる。これにより、機能要件だけでなく、非機能要件としての信頼性や使いやすさを向上させるための視点を養う。この細目で理解すべき範囲は、Webアプリケーションにおけるエラーハンドリングの重要性を認識し、Spring Bootの機能を用いてステータスコードに応じたカスタムエラーページを実装する方法を理解するまで。
|
③ 全45回の講義の総まとめとして、第1回から積み上げてきたWebアプリケーション開発の知識と技術を体系的に整理し、総括を行う。講義の冒頭で触れた「Servlet/JSPによる古典的な開発」の煩雑さと比較しながら、Spring Frameworkが提供する各機能がいかに開発効率と保守性を高めているかを再確認する。具体的には、DI（依存性の注入）によるコンポーネント間の疎結合化、AOP（アスペクト指向プログラミング）による横断的関心事の分離、Spring MVCによるリクエスト処理の構造化、Thymeleafによるビューのテンプレート化、そしてO/Rマッパー（MyBatis）によるデータベース操作の抽象化といった各要素技術が、相互にどのように連携して一つのアプリケーション（ToDoアプリ）を構成しているかを、アーキテクチャ図を用いて俯瞰的に解説する。
また、本講義で学んだ内容は広大なSpringエコシステムの入り口に過ぎないことを示唆する。Spring Bootが提供する自動設定（Auto-configuration）の恩恵を受けつつも、その内部動作原理（アノテーション処理やリフレクションなど）への理解を深めることが、トラブルシューティング能力や応用力につながることを説く。さらに、今後の学習指針として、RESTful APIの設計、マイクロサービスアーキテクチャへの展開、クラウド環境へのデプロイ、単体テスト（JUnit）の自動化など、現代のエンジニアに求められる発展的なトピックとの関連性についても言及する。
最後に、技術は常に進化し続けるものであり、特定のフレームワークの操作方法を覚えるだけでなく、その背景にある設計思想（MVCモデル、レイヤ化アーキテクチャ、セキュリティバイデザインなど）を理解することが、将来どのような新しい技術が登場しても適応できる基礎力となることを強調する。本講義を通じて作成した成果物（ToDoアプリ）は、自身のポートフォリオとして活用できるだけでなく、今後の学習における実験場としても機能することを伝え、継続的な学習を促す。この細目で理解すべき範囲は、本講義で学習した全技術要素の関連性を体系的に理解し、Webエンジニアとしての継続的な学習の必要性と方向性を認識するまで。
|
|
キーワード
|
① Spring Security ② 認証（Authentication） ③ 認可（Authorization） ④ エラーハンドリング ⑤ Webアプリケーションフレームワーク
|
|
コマの展開方法
|
社会人講師
AL
ICT
PowerPoint・Keynote
教科書
コマ用オリジナル配布資料
コマ用プリント配布資料
その他
該当なし
|
|
小テスト
|
授業時間内に、LMS上において該当コマの小テストを実施する。
|
|
復習・予習課題
|
◆今回授業の復習
今回の授業で学習したSpring Securityの導入手順と、認証・認可の違いについて、自身の言葉で説明できるように整理すること。また、作成したToDoアプリケーションにおいて、ログイン機能を有効にした場合の挙動（ログインしていないと一覧画面が見られない、など）と、エラー発生時（存在しないURLへのアクセスなど）の画面遷移を確認し、フレームワークがどのようにリクエストを制御しているか、頭の中で処理フローを追跡してみること。講義全体を通して作成したアプリケーションのソースコード全体を見直し、各クラスの役割を再確認すること。
◆次回授業の予習
本講義は今回で終了となるため、次回の授業に向けた予習課題はない。しかし、今後の学習として、本講義で作成したアプリケーションに対して、独自の機能追加（例えば、ToDoに期限日を設ける、完了フラグを追加する、ユーザのプロフィール編集機能を追加するなど）に挑戦することを推奨する。また、Spring Frameworkの公式ドキュメントや、関連する技術記事に目を通し、本講義で扱わなかったアノテーションや機能について、どのようなものがあるか興味を持って調べてみることは、エンジニアとしての成長に大きく寄与する。
|