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