顧客を別のサイトに送って支払いを処理するアプリケーションがあります。顧客以外の別のサイトは、サーバーのページを呼び出して、支払いのステータスを知らせます。呼び出されたページは、支払いアプリケーションによって指定されたパラメーターを確認し、トランザクションが認識されているかどうかを確認します。次に、データベースを更新してステータスを反映します。これはすべて、顧客との対話なしで行われます。
この機能をJSPとして実装することを個人的に選択しました。ファイルをコンパイルしてパッケージ化し、構成ファイルにエントリを追加するよりも、ファイルシステムにファイルをドロップする方が簡単だからです。
ページの機能を考慮すると、サーブレットが好ましいオプションになると思います。質問は次のとおりです。
JSPは、初めて実行されるときにサーブレットにコンパイルされます。つまり、それらの間に実際の実行時の違いはありません。
ただし、ほとんどの場合、コントローラーにはサーブレットを使用し、ビューにはJSPを使用します。コントローラはJavaクラスであるため、すべてのIDEからツールの完全なサポート(コード補完など)を取得できます。 IDEA頭に浮かぶ)JSPの優れたサポートがあり、その引数は廃止されます。
独自のフレームワークを作成している場合、または単純なJSPで作成している場合は、JSPを引き続き使用してください。パフォーマンスに違いはありません。JSPを作成する方が簡単だと感じた場合は、ぜひ続行してください。
JSP:ユーザーにデータを提示します。ここにビジネスロジックが存在することはありません。また、データベースアクセスも存在しません。
サーブレット:フォームまたは特定のURLからの入力を処理します。通常、人々は、サーブレットの上にStruts/Springのようなライブラリを使用して、プログラミングをクリアします。とにかく、サーブレットは受信したデータを検証し、それをバックエンドのビジネスレイヤー実装(テストケースをコーディングできる)に渡すだけです。次に、結果の値をリクエストまたはセッションに配置し、JSPを呼び出して表示する必要があります。
モデル:Webサイトが処理する構造化データを保持するデータモデル。サーブレットは引数を取り、それらをモデルに入れてからビジネス層を呼び出します。その後、モデルはバックエンドDAO(またはHibernate)とインターフェイスしてデータベースにアクセスできます。
重要なプロジェクトでは、MVC構造を実装する必要があります。もちろん、些細な機能にとってはやり過ぎです。あなたの場合、ステータスなどを更新するためにDAOを呼び出すサーブレットなどを実装します。
JSPは、プレゼンテーション層、ビジネスロジック用のサーブレット、およびバックエンド(通常はデータベース層)コードで使用する必要があります。
説明どおりにJSPを使用できない理由はわかりません(とにかくコンテナーによってサーブレットにコンパイルされます)。 。
JSPは、サーブレットを記述するためのショートカットです。実際、それらはコンパイル前にサーブレットJavaコードに変換されます。名前を覚えていないTomcatサブディレクトリで確認できます)。
サーブレットからJSPを選択するには、単純なルールを使用します。ページにJavaコードよりも多くのhtmlコードが含まれる場合は、JSPに進みます。それ以外の場合はサーブレットを記述します。コンテンツ表示用のJSPおよび制御、検証などのためのサーブレット.
また、プレーンなJavaクラス構文を使用するため、サーブレット内でコードを整理および構造化するのが簡単です。JSPはメソッドを作成できますが、よりモノリシックになりがちです。
2つの非常に単純なルールがあります。
今日、これが一般的な答えではないことはわかっていますが、アプリケーションをゼロから設計するときは、常にJSPを使用します。ロジックが自明でない場合、私は通常のJavaクラスを作成して、JSPから呼び出すうっとうしい作業を行います。サーブレットを使用するべきであるという議論を理解したことがありません。 Javaクラス、より保守性が高い。JSPは、純粋なJavaクラス、そしてもちろん通常のJava =クラスは、サーブレットと同じように保守可能です。多くのprintlnを記述する必要がなく、すべてのマークアップをインラインに配置できるため、JSPでページをフォーマットするのが簡単になります。それらをディレクトリにドロップすると、直接アクセスできます:URLとクラスファイル間の関係を設定することで混乱する必要はありません。すべてのJSPを単一の呼び出しであるセキュリティチェックで開始することにより、セキュリティを簡単に処理できます。ステートメントなので、セキュリティをディスパッチレイヤーに置く必要はありません。
サーブレットを使用する唯一の理由は、URLと結果の実行クラスの間の複雑なマッピングが必要な場合です。たとえば、URLを調べて、セッション状態などに応じて多くのクラスの1つを呼び出す場合。個人的に私はこれをやりたくなかったし、それを見たアプリは維持するのが難しい傾向があります。変更を始める前に、実際に実行されているコードを把握する必要があるからです。
JSPは基本的に、サーブレットコンテナによって自動的にサーブレットにコンパイルされるマークアップであるため、コンパイル手順は両方のインスタンスで発生します。これが、JREのみを必要とするのではなく、JSPをサポートするサーブレットコンテナが完全なJDKを使用可能にする必要がある理由です。
したがって、JSPの主な理由は、ページのレンダリングに必要なコードの量を減らすことです。ページをレンダリングする必要がない場合は、サーブレットの方が優れています。
JSPとサーブレットの違いについて上記のすべての点に同意しましたが、いくつかの追加の考慮事項があります。あなたが書く:
顧客を別のサイトに送って支払いを処理するアプリケーションがあります。顧客以外の別のサイトは、サーバーのページを呼び出して、支払いのステータスを知らせます。呼び出されたページは、支払いアプリケーションによって指定されたパラメーターを確認し、トランザクションが認識されているかどうかを確認します。次に、データベースを更新してステータスを反映します。これはすべて、顧客との対話なしで行われます。
アプリケーションが別のアプリケーションの支払いサービスを使用しています。他のアプリケーションの支払いサービスが変更されると、JSPページが破損するため、ソリューションは脆弱です。または、アプリケーションの支払いポリシーを変更する場合は、ページを変更する必要があります。簡単な答えは、アプリケーションがWebサービスを介してアプリケーションの支払いサービスを使用する必要があるということです。サーブレットもJSPページも消費ロジックを配置するのに適切な場所ではありません。
第二に、これらの線に沿って、ここ数年のサーブレット/ JSPページのほとんどの使用は、SpringやStrutsのようなフレームワークのコンテキスト内に置かれています。 Springをお勧めします。サーバーページからWebサービスゲートウェイロジックからDAOへの必要なものの完全なスタックを提供するからです。 Springのナットとボルトを理解したい場合は、Spring in Actionをお勧めします。 Java(またはC#)などの言語で記述されたエンタープライズアーキテクチャを階層化する方法をよりよく理解する必要がある場合は、FowlerのPatterns of Enterprise Application Architectureをお勧めします。
ほとんどのJavaアプリケーションは最近MVCパターンで構築されています...コントローラ側(サーブレット)でビジネスロジックを実装します。サーブレットコントローラは通常、実際のhtmlを生成するjspにリクエストを転送します。応答(MVCのビュー)目標は、懸念を分離することです...何千もの本がその主題について書かれています。
MVCアーキテクチャでは、サーブレットがコントローラとして使用され、JSPがビューとして使用されます。しかし、どちらも技術的には同じです。 JSPは、コンパイル時(JDeveloperなど)または初回アクセス時(Tomcatなど)にサーブレットに変換されます。本当の違いは使いやすさです。サーブレットを使用してHTMLページをレンダリングするのに苦労することは間違いありません。しかし、常識とは反対に、実際にはかなり複雑なロジックでさえ、JSPの内部で(おそらく準備されたヘルパークラスの助けを借りて)コーディングするのは非常に簡単です。 PHPみんながこれをいつもやってくれます。そして、彼らはスパゲッティコードを作成する落とし穴に陥ります。だからあなたの問題に対する私の解決策:コードが多すぎる場合は、JSPで自由にコーディングしてください。
あなた次第だと思いますか? JSPはJava HTML内であり、サーブレットはJava HTML内でHTML
hmmm ...サーブレットはjspよりも安全です。これは、サーブレットに送信して別のJSPに転送すると、ファイル拡張子が表示されず、ページが何であるかがわからないためです。
しかし、JSPの利点は、そこに簡単にコーディングできることです。
JavaサーブレットでHTMLタグはJavaコーディングに埋め込まれます。JSPではJavaコーディングはHTMLタグに埋め込まれます。
大きな問題のための大きなアプリケーションの場合、サーブレットはJavaコーディング内にさらにHTMLタグを埋め込むことができないため、サーブレットの読み取り、理解、デバッグなどが複雑になります。わかりやすい、デバッグなど.
ありがとう、よろしく、Sivakumar.j
ええ、これはサーブレットでなければなりません。 JSPは開発しやすいかもしれませんが、サーブレットは保守しやすいでしょう。 6か月でランダムなバグを修正し、それがどのように機能したかを思い出そうとすることを想像してください。