パフォーマンスに関する JSP スクリプトレットと MVC の比較
-
26-09-2019 - |
質問
私が面接に来たところ、CTO (最高技術責任者) は、(5 年以上稼働している) システムがあるが、純粋にパフォーマンスを重視して MVC を使用することをまだ望んでいない、と言いました。ほとんどの MVC がリフレクションを使用してメソッドを呼び出すことはわかっていますが (これは本質的に遅い)、多くの MVC (Struts がそれを行っていることは知っていますし、コードを読みました) は呼び出したメソッドをキャッシュするため、メソッドを「見つける」必要はありません。常に呼び出します。
今のところ、彼らはスクリプトレットに固執しています (そして、JSPTag は使用しません)。MVC ではなく純粋にスクリプトレットだけで実行される大規模なパフォーマンスはあるのでしょうか?彼らは、セッションの移行やセッションの追跡などを避けるために、ステートレス セッションとステートフル セッションを優先します。
CTO の言うことが真実である場合、なぜ MVC が依然として好まれるのか (MVC が存在する理由はわかっていますが、パフォーマンスの点で)。
解決
反対の議論:
- 反省はそうではありません それ ここ数年でもう遅くなりました。
- ハードウェアのパフォーマンスはここ数年で非常に向上しました。
- MVC は最終的に開発の高速化につながります。無駄な時間が減る = より多くの $$$ の節約になります。
私ならその仕事をパスするだろう。
他のヒント
これは CTO の論理としてはかなり奇妙なものです。彼は何のことを言っているのか分からないと思います(ヒント:) 彼が効率をそんなに心配しているのなら、Web アプリ全体をアセンブリ言語で書き直したらどうでしょうか?
スクリプトレットに対する議論
スクリプトレットはメンテナンスが難しいことで有名なので、私は好きではありません。彼らは虐待される傾向もあります。最大の特徴は、ビュー ロジックとビジネス ロジックを混同していること、または少なくとも、非常に簡単に同じことを実行したくなることです。
あなた できた 懸念事項を慎重に分離し、データを取り込む (つまり再利用を促進する) サービスを使用してください。しかし、多くの場合、開発者が PHP コードのような JSP (つまり、マークアップと混合されたコード) を作成しているのを見てきました。
あなたがと言っているわけではありません できない JSP を使用して適切なコードを作成します。ただ、それはより難しく (MVC にはより多くの安全策があると感じます)、また JSP は悪用されやすい (と私は感じます) というだけです。
MCV の引数
2 番目の質問に答えると、MVC は本質的に関心事の分離を促進し、個別の領域のロジックが他の領域に浸透することを許可しないため、MVC が推奨されます。
ビュー レイヤはビューのレンダリングのみに関与します。コントローラーからメタデータを取得し、ビューを使用してデータを表示します。ここではビジネス ロジックについては心配しません (心配する必要はありません)。
コントローラーは交通警察のように機能し、リクエストを適切な宛先にリダイレクトします。通常、コントローラーはすべてのビジネス ロジックを実行するサービスを呼び出すことになります。
モデルは、アプリケーション ドメインのデータと動作を担当します。モデルはその状態 (つまり、これがビューに送信するメタデータ) に関するリクエストに応答し、(コントローラーからの) 状態を変更するように指示する命令にも応答します。
反映は実際にはそれほど遅くありません。また、最近のコンピューターは非常に高速で、メモリも大量に搭載されています。パフォーマンスはそれほど気にする必要はありません。
MVC パターンは、さまざまな懸念事項間の明確な分離を促進し、開発者がクリーンで堅牢かつ保守しやすいコードを簡単に作成できるようにします。
スクリプトレットを超えるMVCの利点は、完全に他の回答に記載されているが、1点が見落とされています。
反射は、直接メソッド呼び出しに比べていくつかのオーバーヘッドを導入します。あなたが頻繁に簡単なメソッドを呼び出すためにリフレクションを使用するときに問題になります。しかし、オーバーヘッド単一の反射の呼び出しによって導入することは、一般的なWebアプリケーションでの処理時間全体の要求に比べて重要ではありません。そのためではない、この特定のケースでは、パフォーマンス上の理由から使用反射による決定は奇妙に聞こえるます。