今日は劉暁愛がJavaを独学して105日目。
ご視聴ありがとうございました。
それでは、今日の勉強を始めましょう：
登録業務を学んだ後は、ログインという新しい機能を学び始めます。
機能の実装は基本的に3つのステップで行われます：
- フロントエンドはバックエンドサーバにリクエストを送信します。
- バックエンドはデータベースにアクセスし、データを照会します。
- フロントエンドはレスポンスデータに基づいて別のレンダリングを行います。
フロントエンドはリクエストを送信します
登録ページの代わりに、フロントエンドが提供する静的リソース内のlogin.htmlファイルであるログインページになりました。
そのファイルに対応するjsコードを記述します：
コード中のconsole.log()は、コードが正しく実行されているかどうかをチェックするためのもので、コードが正常であればこれらを削除します。
フォーム提出イベント
そのページのログインフォームのidを見つけ、それに基づいてsubmitイベントをバインドします。
ログインページでは、ユーザーが送信するとトリガーされます。
フォームデータのシリアライズ
データが複数ある場合、ログイン時にデータをシリアライズし、シリアライズされたデータを提出することを選択できます。
非同期リクエスト送信
パラメータはまだ4つ：
- loginData: リクエストに含まれるデータ。
- function(result){}: コールバック関数、resultはバックグラウンドのレスポンスのデータです。
- "json"：データはjson形式で転送されます。
falseを返すと、フォームはデフォルトで送信されないように設定されます。
Javaバックエンドコードの記述
Javaの3層アーキテクチャでのコード記述：
1ウェブレイヤー
パラメータ login を持つフロントエンドから送信されたリクエストはログインメソッドに対応します：
要求されたデータの取得
ログインページには複数のデータがあるので、getParameterMap()メソッドを使用してデータを取得します。
ユーザーオブジェクトにデータを格納
Javaではあらゆるものがクラスになり得ます。
フロントエンドのリクエストのデータとデータベースのデータは、どちらもJavaのクラスに対応することができます。
ここでは、BeanUtilsのpopulateメソッドを使用して、リクエストデータをユーザーオブジェクトに変換しています。
ビジネス層の処理と結果
ビジネス・レイヤーの戻り値はユーザー・オブジェクトです：
- これが空でなければ、ログインは成功です。
- 空の場合、該当するデータは見つからず、ログインに失敗します。
結果をキーと値のペアとしてmapに格納します：
- ログイン成功：true を返し、対応するユーザオブジェクトを返します。
- ログイン失敗：false とそれに対応するエラーメッセージを返します。
jsonデータへの変換とレスポンス
このステップは言うまでもありませんし、何度も書かれています。
2サービス層
パスワードを md5 で暗号化します。
ログインページでユーザーが入力するパスワードは平文で、データベースに保存されるデータはmd5で暗号化された暗号文です。
そのため、まず平文を暗号文に変換し、その暗号文を使ってデータベースに照会る必要があります。
ひとつ特筆すべきことがあります：
暗号文をUSERにリセットすることを忘れないでください。
ダオ層クエリデータ
メソッド名の命名規則については、name: query user data by email and password を参照してください。
結果はユーザーオブジェクトです。
3層
jdbcTemplateを使用してデータを照会します：
クエリーメソッドを使用している場合、クエリーの結果はコレクションになります。
そして実際、現実の論理的判断によれば、ログイン・ビジネスはUSERオブジェクトにしか照会ることができません。
ここでは queryForObject() メソッドが使用されており、メソッド名を見れば、オブジェクトの形式でデータを照会していることがわかります。
もちろん、クエリーメソッドを直接使用して、コレクションの最初の要素をフェッチすることもできます。
ここでひとつ、心に留めておいていただきたいことがあります：
アクティブなtry...catch例外は、クエリで要素が見つからない場合にjdbcTemplateがエラーを報告するためです。
queryForObject()メソッドのソースコードを確認してください：
このコード片は、クエリされるUserオブジェクトの数が0の場合、基礎となるUserオブジェクトが例外を投げることを意味します。
代わりに、この例外をキャッチして、フロントエンドにデータが照会されなかったことを伝える必要があります。
もちろん、ソースコード中の以下の例外は、複数のUserオブジェクトがクエリ可能な場合、基礎となる部分も例外を投げることを意味します。
そして、例外のこの作品は、一般的に表示されません、結局のところ、どのようにログインビジネスのユーザー名とパスワードは、複数のユーザーに対応しています。
ログインユーザー名が一意であることを保証するために、データテーブルを設計する際にこれを考慮する必要があります。
フロントエンドページのレンダリング
1 応答データ形式
Servletレスポンスのデータ形式はjsonです。
では、実際にブラウザ上でデータはどのように見えるのでしょうか？
これはブラウザのF12パンチコンソールで見ることができます：
ログイン成功
jsonデータは、1つ以上のキーと値のペアとして理解することができます。
- loginFlag対応する値はtrueです。;
- longinUser: 対応する値はユーザーデータです。
ユーザーログインの失敗
- longinFlag対応する値はfalseです；
- errorMsgエラーメッセージ
このデータはどこから来たのですか？
サーブレット内で自分で作成したマップのコレクションにデータを追加します。
そして、jsonは、ブラウザとサーバー間の転送を容易にするためであり、実際には、本質を理解するためのマップに従うことができます。
2 レンダリングページ
loginFlagに対応する値によって、異なる処理が行われます：
LoginFlagはtrueです。
ログインに成功したので、locationを使ってホームページにジャンプします。
loginFlag が false
ログインページにはエラーメッセージを示すタグがあり、そのidはerrorMsgです。
ログインに失敗したので、そのページにエラーメッセージを追加してください。
最後の
ご視聴ありがとうございました。
