Check paragraph show below from Struts Survival Guide.
Here are some more downsides of using DynaActionForms 1. The DynaActionForm bloats up the Struts config file with the xml based definition. This gets annoying as the Struts Config file grow larger. 2. The DynaActionForm is not strongly typed as the ActionForm. This means there is no compile time checking for the form fields. Detecting them at runtime is painful and makes you go through redeployment. 3. ActionForm can be cleanly organized in packages as against the flat organization in the Struts Config file. 4. ActionForm were designed to act as a Firewall between HTTP and the Action classes, i.e. isolate and encapsulate the HTTP request parameters from direct use in Actions. With DynaActionForm, the property access is no different than using request.getParameter(�..�). 5. DynaActionForm construction at runtime requires a lot of Java Reflection machinery that can be expensive. 6. Time savings from DynaActionForm is insignificant. It doesn�t take long for today�s IDEs to generate getters and setters for the ActionForm attributes.(Let us say that you made a silly typo in accessing the DynaActionForm properties in the Action instance. It takes less time to generate the getters and setters in the IDE than fixing your Action code and redeploying your web application) That said, DynaActionForms have an important role to play in the project lifecycle as described earlier, which they do best and let us limit them to just that. Use them with caution, only when you absolutely need them.