0

不完全ですが小さなWebプロジェクト（WebSphere7で実行されているJavaEE 5）を継承しました。

プロジェクトの大部分は、URLを介して直接アクセスされるJSPで構成されており、ほとんどのJSPは、必要なEJB（サービス）への独自の参照を検索します。また、JSPのHTMLコードによって送信されるすべてのフォームにサーブレットがあります。

建築的に言えば、これに何か問題がありますか？

私はMVCデザインを持っている方が良いと思っていました。すべてのHTMLと埋め込みJavaスクリプトレットをJSFタグとマネージドBeanに変換したくないので、すべてをJSFに変換したくありません。

StrutsまたはSpringMVCは、WebSphereに付属しているJava EE 5ツールキットの一部ではないため、実際には使用したくありません。また、追加のライブラリと構成ファイルで複雑さを増したくありません。 。

コマンドを受け入れ、コマンドオブジェクトを動的にビルドして実行し、JSPビューにリダイレクトする「ControllerServlet」を使用して、独自の小さなMVCを構築することを考えていました。

しかし、もう一度自問します。サーブレットに投稿するJSPに「間違った」ものはありますか？それは実際にはその単純さの点で一種のエレガントです。

どう思いますか？

どんな提案でも大歓迎です！ロブ

4

1 に答える 1

2

あなたはかなり主観的/ローカライズされた質問をしています。しかし、ああ。

個々のサーブレットにサブミットする個々の JSP には、技術的に何の問題もありません。唯一の実際の問題は、サーブレットに、リクエスト パラメータの収集、それらの変換/検証、Bean プロパティの設定、アクションの呼び出し、ナビゲーションの実行などの非常に一般的なタスクの重複したコードが含まれていることが判明した場合です。これは DRY ではなく、単一のフロント コントローラーと明確に定義されたライフサイクルを備えた MVC フレームワークが解決すべきことです。

または、サーブレットのタスクが実際に自家製のコードで適切にリファクタリングされ、これらの一般的なタスクを実行する場合、元の開発者以外の誰もこのカスタム フレームワークの内外を知らないため、これは保守性が低くなります。そのため、新しい開発者が将来の他のWeb アプリで目にすることのない別のフレームワークを再度学習せずに、この Web アプリを維持しようとする人を見つけるのは困難です。そのため、企業は通常、JSF、Spring MVC、Stripes、Struts などの既存の十分に開発された MVC フレームワークを採用しています。

于 2012-05-14T19:07:21.440 に答える