blog

ウェブサイトに登録する際に記入したデータを重複させないことが重要なのはなぜか?

前置きはこのくらいにして、登録ページのビジネスロジックに移りましょう。以下はその一部です:\n\n\n例えば、ユーザー名とパスワードは空ではいけません。例えば、電話番号はやみくもに記入することはできま...

Jan 5, 2021 · 5 min. read
シェア

今日は劉暁愛の独学ジャワ102日目。

ご視聴ありがとうございました。

それでは、登録ページのビジネスロジックを学んでいきましょう。:

データの完全性と正当性を保証するためです:

  • 例えば、ユーザー名とパスワードを空にすることはできません。
  • 例えば、電話番号はやみくもに記入することはできません。

例えば、異なるユーザーが同じEメールを使って登録することはできません。

バックエンドのデータ検証を実装するには?

実装には、Javaの古典的な3層アーキテクチャを使用する必要があります。

まず、リクエストを送信するフロントエンドページです。

Javaコードを書くとき、フロントエンドのページはリクエストを送信しなければなりません。

登録ボタンをクリックする前にリアルタイムでユーザーを確認する必要があるため、ajaxを使用して非同期リクエストを実装し、非同期リクエストを送信する必要があります:

ブラーイベントのバインド

blurイベントをフォームのemailデータフィールドにバインドします:

このイベントは、登録ページでデータを入力している間に、ユーザーがEメールデータフィールドを離れるとすぐにトリガーされます。

conso.log("劉暁愛")というコードは、イベントが正しくトリガーされるかどうかをテストするために使われます。

ブラウザのコンソールが "Liu Xiaoxiao Ai "と出力した場合、イベントは正常にトリガーできることを意味します。

取得要求の送信

get() メソッドには 4 つのパラメータがあります:

"/checkEmailServlet":リクエストを受け付けるサーブレットがあるサーバーのurl、つまりリクエストパス。

{email:email}:送信リクエストパラメータ:

  • key=value&key=value
  • {key:value,key:value...}

function {}: コールバック関数。リクエストが成功したときに起動されます。

"json":リターン・パラメータのタイプ、xml、htmlなどがありますが、ここではjsonを使用します。

バックエンドのコード記述

1ウェブレイヤー

上記の送信されたリクエストを受け付けるサーブレットを作成します:

フロントエンドリクエストパラメータの受け入れ

ajaxで送信されたデータはEメールです。対応するパラメータを取得するには、リクエスト・ドメイン・オブジェクトを使用するだけです。

サービス層で処理

サービス・レイヤにUserServiceインタフェースとそれに対応する実装クラスを作成します。

サービスレイヤーは結果をブール値としてウェブレイヤーに返します:

  • 真の値はメールボックスが存在することを示します。
  • 偽の値はメールボックスが存在しないことを示します。

応答データ

処理されたデータをフロントエンドに応答します。ajax送信のデータはjsonなので、応答する前に処理結果をjson形式に変換する必要があります。

JSON.toJSONString()を使用すると、対応するデータをJSON文字列に変換できます。

2サービス層

サービス層では,サービスインタフェースが実装クラスに対応します.実装クラスを格納するために,サービスパッケージの下にimplパッケージが作成されます.

ダオ層はデータのクエリに特化しており、サービス層ではダオ層のメソッドを呼び出すだけです。

電子メールの一意性の検証はUserServiceのサービスの1つに過ぎないため、UserServiceに関連する他のサービスも存在します。

そこで、ダオ階層オブジェクトをメンバ変数として設定し、複数のメソッドがそのダオ階層オブジェクトを参照できるようにします。

ダオ層のクエリデータ

queryUserByEmail():電子メールに基づいてユーザーを照会ます。

これは一般的に、一目で理解しやすい命名法であり、そのメソッドが何を実現するのかが一目でわかります。

審判検索結果

1つ以上のユーザ・データが照会された場合、メールボックスはすでに存在しているので、戻り値はtrueです。

クエリされたデータが空の場合、メールボックスが存在しないことを意味するので、戻り値は偽です。

3層

ダオ・レイヤーもサービス・レイヤーと同様、実装クラスに対応するインターフェースです。

jdbcTemplateの初期化

c3p0接続プールを使用してデータソースを取得し、jdbcTemplateを作成します。

同じ意味で、複数の企業がテンプレートを使用する必要があるので、メンバー変数として設定します。

クエリデータ

クエリメソッドを介してクエリは、jdbcTemplateの研究では、メソッドを詳細に話すときに、簡単なレビューを行うには、3つのパラメータの合計の1つです:

  • sql結果は sql 文です。
  • RowMapperマッパーです。
  • email:SQL文のワイルドカードとしても知られています。

クエリー結果を直接サービス・レイヤーに返すだけです。

ページのレンダリングとテスト

バックエンドは処理されたデータをjson形式のフロントエンドに応答し、フロントエンドは異なる結果に応じて異なるページをレンダリングします:

リクエストを送信する前に、メールボックスのフロントエンド検証を実行します。

バックエンドにリクエストが存在しなかったり、フォーマットが間違っていたりしても、リクエストを送る必要はありません。

正規表現を使ってマッチさせます:

  • リクエストを満たす:サーバーにgetリクエストを送信します。
  • 要件が満たされていない:ページに「入力されたメールボックスは合法ではありません」というメッセージとともにエラーが報告されます。

リクエスト

result.checkEmailで対応するデータを取り出します:

  • trueの場合:メールボックスはすでに存在し、エラーは "メールボックスはすでに登録されています "というメッセージとともにページに報告されます。
  • false: メールボックスが既に存在する場合、ページ情報は "√" と表示されます。

担当者を書き終えたら、フロントエンドのページでテストを行います

テスト用に、まずデータをデータベースに挿入します。

Emailに1を入力すると、メールボックスの命名規則に適合しないため、「入力されたメールボックスは合法ではありません」というエラーが報告されます。

データベースにメールボックスが存在しないため、正常に登録でき、チェックが表示されます。

メールボックスはすでにデータベースに存在しており、検証の結果「メールボックスは登録済みです。

と③の違いは、①はフロントエンドの検証で、バックエンドにはリクエストを送らず、③はバックエンドの検証で、結果が出た後にデータベースに照会るリクエストを送ります。

最後に

ご視聴ありがとうございました。

Read next

実装、api、compileOnlyの違い

compile 依存関係は廃止され、and api に置き換えられました。\nprovided は compile only に置き換えられました。\napk は runtime only に置き換えられました。\napi: 2.x バージョンの comp と同じ依存関係です。

Jan 5, 2021 · 1 min read