生産段階でDynaActionFormを使わない方が良いわけ
この間紹介した本"Struts Survival Guide"より。著者の意見では、DynaActionFormsはプロトタイプの段階ではいろいろとプロパティが簡単に変更できたりと便利だが、最終的には通常の ActionFormを使うべきだと。
DynaActionFormsの欠点/ActionFormを使う利点:
- DynaActionFormはstruts-config.xml内に定義するが、フォームが増えるにつれてconfigファイルも大きくなり、メインテナンスしにくくなる。
- DynaActionFormはActionFormのように、フォームフィールドのコンパイルタイムでのチェックがない。 ランタイムでバグを見つけるのは大変で、再起動も必要になってくる。
- 通常のActionFormだと、DynaActionFormのようにconfigファイルにつっこまれるのとは違って、パッケージに整理することができる。
- ActionFormはもともと、HTTPリクエストパラメータをActionからの直接アクセスと切り離すために、HTTPとActionクラスとの間にはいるFirewallの役割もなすためにデザインされた。これがDynaActionFormだと、プロパティへのアクセスは"request.getParameter("...")"と全く変わらないことになる。
- ランタイムでDynaActionFormをコンストラクトするのにはJava Reflectionを使うので、高くつく(リソースをたくさん使う)。
- DynaActionFormを使うことによって得することは少ない。 IDEを使えばgetters, settersをジェネレートするのは簡単だ。
と、こう言われると納得です。 プロジェクトを仕上げる課程で重要な役割を果たしてくれるDynaActionFormですが、最後はやはりActionFormですね。