サーブレット&JSPの基本｜みんなのショッピングのログイン機能を設計しよう

サーブレット&JSPの基本｜みんなのショッピングのログイン機能を設計しよう

ログイン機能は、画面だけでは完成しない。テーブル、画面遷移、サーブレット、JSP、サーバサイド処理を整理して、みんなのショッピングの入口を設計しよう

これまで、Servlet、JSP、フォーム、リクエストパラメータ、スコープ、JDBC、DAO、EL式、JSTLなど、Webアプリケーションを作るために必要な基本を学習してきました。

これらの知識を組み合わせると、ログイン機能を持つWebアプリケーションを作れるようになります。

今回の題材は、ショッピングサイト「みんなのショッピング」です。

ショッピングサイトでは、利用者がログインしてから商品を見たり、注文したり、会員情報を確認したりする流れがよく使われます。

その入口になるのがログイン機能です。

ただし、ログイン機能はログイン画面を作るだけでは完成しません。

利用者が入力したユーザーIDとパスワードを受け取り、データベースに登録されている会員情報と照合し、成功した場合はセッションスコープにログイン情報を保存します。

失敗した場合は、もう一度ログイン画面へ戻す必要があります。

このように、ログイン機能には画面、サーブレット、JSP、リクエストパラメータ、セッションスコープ、BO、DAO、Entity、データベースが関係します。

いきなりプログラムを書き始めると、途中で名前がずれたり、必要な情報が足りなかったり、画面遷移が分かりにくくなったりします。

そこで、この記事ではプログラミングの前に、ログイン機能の設計を行います。

プロジェクト名はstudyとします。

データベース名はminnaMarketとします。

テーブル名はCUSTOMERSとします。

テスト用アカウントは、ユーザーIDをmiyu、パスワードを1234とする会員情報に変更して説明します。

この記事では、H2 DatabaseでminnaMarketデータベースを作成し、CUSTOMERSテーブルを作成する手順も含めて整理します。

ログイン機能で設計する内容

ログイン機能を作るには、まず何を設計する必要があるのかを確認します。

ログイン機能では、利用者がログイン画面でユーザーIDとパスワードを入力します。

その入力値をサーブレットが受け取り、ログイン処理を担当するBOへ渡します。

BOはDAOを呼び出し、DAOはデータベースのCUSTOMERSテーブルを検索します。

該当する会員が見つかればログイン成功です。

見つからなければログイン失敗です。

ログイン機能で決めること

このように整理してからプログラムを作ると、どのクラスを作るのか、どのJSPが必要なのか、どの値を受け渡すのかが分かりやすくなります。

H2 Databaseでデータベースを作成する

まず、H2 Databaseにログイン機能で使うデータベースを作成します。

ここでは、ショッピングサイト「みんなのショッピング」用のデータベースとして、minnaMarketを作成します。

H2 Databaseでは、H2コンソールを使ってデータベースへ接続します。

データベースを新しく作成するときは、最初に組み込みモードを使います。

minnaMarketデータベース作成時の設定

H2コンソールを起動したら、保存済み設定でGeneric H2 (Embedded)を選択します。

JDBC URLにjdbc:h2:~/minnaMarketを入力します。

ユーザー名はsa、パスワードは空文字のままにします。

その状態で接続ボタンをクリックすると、minnaMarketデータベースが作成されます。

すでに同じ名前のデータベースが存在する場合は、そのデータベースへ接続されます。

データベース作成の手順

データベースを作成できたら、いったん切断します。

この後のテーブル作成や初期データ登録では、サーバーモードで接続します。

サーバーモードでminnaMarketデータベースに接続する

テーブルを作成したり、初期データを追加したりする作業では、サーバーモードでminnaMarketデータベースに接続します。

H2コンソールの保存済み設定でGeneric H2 (Server)を選択します。

JDBC URLには、次の値を指定します。

jdbc:h2:tcp://localhost/~/minnaMarket

サーバーモード接続時の設定

サーバーモードでは、Javaプログラムから接続するときと同じ形式のJDBC URLを使います。

今後、DAOからデータベースへ接続するときも、jdbc:h2:tcp://localhost/~/minnaMarketを使います。

CUSTOMERSテーブルの設計

ログイン機能では、入力されたユーザーIDとパスワードが正しいかどうかを確認する必要があります。

そのため、会員情報を保存するテーブルを作成します。

ここでは、テーブル名をCUSTOMERSとします。

CUSTOMERSテーブルには、ユーザーID、パスワード、メールアドレス、氏名、年齢を保存します。

CUSTOMERSテーブル

CUSTOMER_IDは、会員を一意に識別するための列です。

同じCUSTOMER_IDを持つ会員が複数いると、ログイン時にどの会員なのか判断できなくなります。

そのため、CUSTOMER_IDにはPRIMARY KEYを指定します。

LOGIN_PASSは、ログイン時に入力されたパスワードと照合するための列です。

EMAIL、CUSTOMER_NAME、AGEは、会員登録機能やログイン後の表示などで使える会員情報です。

CUSTOMERSテーブルを作成するSQL

サーバーモードでminnaMarketデータベースへ接続したら、H2コンソールのSQL入力欄で次のSQLを実行します。

CREATE TABLE CUSTOMERS (
    CUSTOMER_ID VARCHAR(12) PRIMARY KEY,
    LOGIN_PASS VARCHAR(12) NOT NULL,
    EMAIL VARCHAR(100) NOT NULL,
    CUSTOMER_NAME VARCHAR(40) NOT NULL,
    AGE INT NOT NULL
);

このSQLを実行すると、minnaMarketデータベースにCUSTOMERSテーブルが作成されます。

SQLの内容

テーブルを設計するときは、列名、型、制約を決めます。

列名は、Java側のEntityやDAOで扱う名前にも関係してきます。

たとえば、CUSTOMER_ID列はJava側のcustomerIdフィールドに対応させると分かりやすくなります。

テスト用アカウントを登録するSQL

ログイン機能を先に作る場合、まだユーザー登録機能がありません。

そのため、ログイン成功を確認するためには、事前にテスト用アカウントを登録しておく必要があります。

ここでは、次の会員情報をCUSTOMERSテーブルに追加します。

INSERT INTO CUSTOMERS
(CUSTOMER_ID, LOGIN_PASS, EMAIL, CUSTOMER_NAME, AGE)
VALUES
('miyu', '1234', 'miyu.tanaka@example.jp', '田中 美優', 28);

アカウントが作成できたら、いったん切断します。

登録されるテスト用アカウント

ログイン機能の動作確認では、ユーザーIDにmiyu、パスワードに1234を入力した場合にログイン成功となる想定です。

それ以外の組み合わせを入力した場合は、ログイン失敗として扱います。

図1：minnaMarketデータベースとCUSTOMERSテーブル

この図から分かること

ログイン機能では、利用者が入力したユーザーIDとパスワードを、CUSTOMERSテーブルに保存されている情報と照合します。

minnaMarketデータベースには、みんなのショッピングで扱う会員情報を保存します。

CUSTOMERSテーブルでは、CUSTOMER_IDを主キーとして会員を識別します。

LOGIN_PASSはログイン認証に使うパスワードです。

EMAIL、CUSTOMER_NAME、AGEは、会員情報として扱うための列です。

開発順序を決める

ログイン機能とユーザー登録機能の両方を作る場合、どちらから開発するかを決める必要があります。

ユーザー登録機能を先に作れば、画面から会員情報を登録できます。

一方、ログイン機能は、フォーム入力、POST送信、認証処理、セッションスコープへの保存という基本的な流れを確認しやすい機能です。

ここでは、まずログイン機能から作ることにします。

開発順序を決めるときの考え方

ログイン機能をユーザー登録機能より先に作る場合は、登録済みの会員がいない状態になりやすいです。

そのため、SQLでテスト用アカウントを登録しておきます。

これにより、ログイン成功とログイン失敗の両方を確認できます。

画面の設計

次に、ログイン機能で必要になる画面を設計します。

画面設計では、画面の種類、表示する内容、入力する内容、画面遷移のきっかけを整理します。

みんなのショッピングのログイン機能では、次の3つの画面を使います。

ログイン機能で使う画面

ログインに失敗した場合は、ログイン画面へ戻す設計にします。

今回は入門者向けに、ログイン失敗専用の画面は作成しません。

ログイン失敗時は、ログイン画面を再表示する流れにします。

画面遷移図で流れを整理する

画面遷移図とは、画面と画面のつながりを表した図です。

ログイン機能では、トップ画面、ログイン画面、ログイン成功画面の関係を整理します。

ログイン機能の画面遷移

画面遷移図では、画面名だけでなく、遷移のきっかけも書きます。

ログインをクリックしたらログイン画面へ進む。

ログインボタンをクリックしたら認証処理を行う。

認証に成功したらログイン成功画面へ進む。

認証に失敗したらログイン画面へ戻る。

このように、画面の流れを先に決めておくと、サーブレットとJSPの設計がしやすくなります。

各画面の入出力項目

画面ごとに、表示する情報と入力する情報を整理します。

画面ごとの入出力項目

ログイン画面で入力されたユーザーIDとパスワードは、POSTリクエストでサーブレットへ送信されます。

ログイン成功画面では、セッションスコープに保存されたユーザーIDを表示します。

図2：みんなのショッピングのログイン画面遷移図

この図から分かること

ログイン機能では、トップ画面、ログイン画面、ログイン成功画面を使います。

トップ画面でログインをクリックすると、ログイン画面へ移動します。

ログイン画面で正しいユーザーIDとパスワードを入力すると、ログイン成功画面へ進みます。

認証に失敗した場合は、ログイン画面へ戻ります。

画面遷移を図にしておくと、必要な画面と移動のきっかけが分かりやすくなります。

サーブレットクラスとJSPファイルの設計

画面の設計ができたら、次にサーブレットクラスとJSPファイルを設計します。

サーブレットは、リクエストを受け取り、処理の流れを制御します。

JSPは、画面を表示します。

みんなのショッピングのログイン機能では、次のサーブレットとJSPを使う設計にします。

サーブレットとJSPの一覧

ファイル名は、みんなのショッピングのログイン機能に合わせてアレンジしています。

MarketTopServlet.javaはトップ画面を表示するサーブレットです。

CustomerLoginServlet.javaはログイン画面の表示とログイン処理を担当します。

marketTop.jsp、customerLogin.jsp、customerLoginOK.jspは画面表示を担当するJSPです。

リクエストとレスポンスの流れ

次に、GET、POST、フォワード、リダイレクト、レスポンスの流れを整理します。

ログイン機能のリクエスト設計

画面からのリクエスト先は、原則としてサーブレットにします。

JSPへ直接アクセスさせるのではなく、サーブレットがリクエストを受け取り、必要なJSPへフォワードします。

この構成にすると、サーブレットがコントローラ、JSPがビューという役割になります。

リクエストパラメータを決める

ログイン画面では、ユーザーIDとパスワードを入力します。

この2つの値は、POSTリクエストでCustomerLoginServletへ送信します。

フォームから送信する値には、name属性で名前を付けます。

その名前を、サーブレット側のrequest.getParameterで取得します。

リクエストパラメータ

JSP側のname属性と、サーブレット側のrequest.getParameterに指定する名前は一致している必要があります。

たとえば、JSP側でname属性をcustomerIdにした場合は、サーブレット側でもrequest.getParameter("customerId")で取得します。

ここがずれていると、入力値を受け取れません。

スコープに保存する情報を決める

ログインに成功したら、ログイン中のユーザーIDをセッションスコープに保存します。

セッションスコープに保存しておくことで、ログイン成功画面や、その後の画面でもログイン中の利用者を識別できます。

スコープ設計

CustomerLoginServletは、ログイン成功時にセッションスコープへcustomerIdを保存します。

customerLoginOK.jspは、EL式とJSTLを使ってcustomerIdを表示します。

拡張した画面遷移で関係を整理する

画面遷移図に、サーブレット、JSP、リクエストパラメータ、スコープを加えると、実装に近い設計図になります。

拡張した画面遷移の内容

この段階で、MVCのVとCに関する設計が整理できます。

VはView、つまり画面表示を担当するJSPです。

CはController、つまりリクエストを受け取って処理の流れを制御するサーブレットです。

サーブレットクラスとJSPファイル設計のチェックポイント

拡張した画面遷移を作ったら、次の点を確認します。

チェックポイント

ログイン成功画面でユーザーIDを表示するには、CustomerLoginServletがセッションスコープにcustomerIdを保存している必要があります。

また、customerLoginOK.jspは、そのcustomerIdを表示できる必要があります。

このように、サーブレット側で保存する情報と、JSP側で表示する情報がつながっているか確認しましょう。

サーバサイドの設計

最後に、サーバサイドの設計を行います。

サーバサイドの設計では、サーブレットにリクエストが届いてから、JSPでレスポンスを返すまでの処理を詳しく決めます。

ログイン機能で特に重要なのは、ログインボタンがクリックされ、CustomerLoginServletのdoPostが実行される場面です。

ここでは、入力されたユーザーIDとパスワードを使って、CUSTOMERSテーブルを検索します。

ログイン成功時のサーバサイド処理

この流れを設計しておくと、CustomerLoginServlet、CustomerLoginLogic、CustomersDAO、CustomerLogin、CustomerAccountの役割がはっきりします。

BO、DAO、Entityを使って設計する

今回のログイン機能では、サーバサイドの処理をBO、DAO、Entityに分けて考えます。

サーバサイドで使うクラス

BOはBusiness Objectの略です。

アプリケーションの中心となる処理を担当します。

今回であれば、CustomerLoginLogicがログイン認証の処理を担当します。

DAOはデータベースアクセスを担当します。

今回であれば、CustomersDAOがCUSTOMERSテーブルを検索します。

Entityは、アプリケーション内で扱うデータを表すクラスです。

CustomerLoginは入力されたログイン情報を表します。

CustomerAccountはCUSTOMERSテーブルの1件分の会員情報を表します。

図3：ログイン成功時の基本アーキテクチャ図

この図から分かること

ログイン成功時には、customerLogin.jspからCustomerLoginServletへPOSTリクエストが送信されます。

CustomerLoginServletは、リクエストパラメータcustomerIdとloginPassを取得し、CustomerLoginインスタンスを作成します。

CustomerLoginLogicはCustomerLoginを受け取り、CustomersDAOを使ってCUSTOMERSテーブルを検索します。

該当する会員が見つかった場合、ログイン成功と判断します。

CustomerLoginServletはcustomerIdをセッションスコープに保存し、customerLoginOK.jspへフォワードします。

この図により、Servlet、BO、DAO、Entity、JSPの役割と連携が整理できます。

ログイン失敗時の設計

ログインに失敗した場合は、ログイン画面へ戻します。

成功時と失敗時を1つの図にまとめると、図が複雑になりやすくなります。

そのため、失敗時の流れは別に整理しておくと分かりやすくなります。

ログイン失敗時の流れ

ログイン失敗時は、セッションスコープにcustomerIdを保存しません。

認証に成功していないためです。

成功時と失敗時で、スコープに保存する情報や遷移先が変わる点を、設計段階で決めておきます。

基本アーキテクチャ図を作る目的

基本アーキテクチャ図は、プログラミングをしやすくするために作る設計図です。

きれいに描くことよりも、実装時に迷わないことが大切です。

基本アーキテクチャ図に書くとよい情報

図が複雑になりすぎる場合は、成功時と失敗時で分けて考えます。

分かりにくい図は、誤解の原因になることがあります。

自分がプログラムを書くときに、何をどの順番で作ればよいか分かる図にすることが大切です。

設計は最初から完璧でなくてもよい

設計は大切ですが、最初から完全な設計を目指しすぎる必要はありません。

実際にプログラムを書き始めてから、不足や矛盾に気付くこともあります。

たとえば、ログイン失敗時にエラーメッセージを表示したくなるかもしれません。

ログイン成功画面でユーザーIDだけでなく会員名も表示したくなるかもしれません。

ユーザー登録機能を追加するときに、CUSTOMERSテーブルに登録日や住所の列を追加したくなるかもしれません。

そのようなときは、設計を見直し、プログラムにも反映します。

設計後に見直すポイント

設計の誤りに気付いたときは、そのまま無理に進めず、設計を直します。

修正を重ねることで、どこを先に考えておくべきかが少しずつ分かるようになります。

プログラミング前に確認しておきたい設計資料

ログイン機能のプログラミングに入る前に、次の資料がそろっているか確認しましょう。

設計資料の確認

ここまで整理できれば、次の記事で実際にプログラムを作成しやすくなります。

いきなり作るのではなく、先に設計してから作る。

この流れを意識することで、ServletとJSPを使ったWebアプリケーション開発を落ち着いて進められるようになります。

次の記事では、この設計をもとに、Entity、DAO、BO、サーブレット、JSPを順番に作成して、ログイン機能を完成させる構成にできます。