Greetings:
I have been following this list for a while now and it seemed fairly clear
to me what some of the options for using form beans are.
I know that Struts does not force you to do to much it seemed that the
overriding theme was to try keep form beans ignorant of the datasource.
The new Dynabeans appear to carry this a step further.
So I raised my eyebrow when I read:
"In my example I'll further cloud the issue by, perhaps somewhat
controversially,
packaging the persistency mechanism in the form bean. "
and:
" EJBs are wonderful creatures, but they can be cumbersome to use with JSP.
If the EJB is embedded in a form bean, much of this awkwardness disappears."
Are there any opinions on this?
Snippet from the Java Pro Article:
"In my example I'll further cloud the issue by, perhaps somewhat
controversially,
packaging the persistency mechanism in the form bean.
Technically a persistent copy of the bean's data is a view,
so now we have a model that incorporates dispatcher and view characteristics, as
well.
This would seem to negate the reason for having a framework like Struts,
but this design has a couple of redeeming features.
First, because the validation and SQL code are heavily dependent on what
properties the form bean possesses,
it's easier to maintain them as a unit. Because we are only interested in the
form bean's properties here,
the "heavy" dispatcher and view components are still safely isolated.
Secondly, when used with the html tag library, the form bean can contain other
objects, which can be referenced using "dot" notation.
This is a great convenience when working with predefined objects because
Java doesn't support multiple inheritance. It avoids the tedious manual effort
of
writing form bean get/set logic for each field in of each internal object.
The convenience is multiplied even further when your inner object is an EJB
normally a very cumbersome object to reference in a JSP page.
EJBs are wonderful creatures, but they can be cumbersome to use with JSP.
If the EJB is embedded in a form bean, much of this awkwardness disappears.
Furthermore, this separates the controller and model, and the persistency view
aspects are reduced to almost nothing,
because the EJB container handles persistency details for us.
Thus, the form bean becomes almost a pure dispatcher and all's right with the
world again.
Well, mostly right. An EJB with lots of properties carries a large RMI overhead
if it is updated on
a per-property basis the way that the ActionServlet normally does for form
beans.
For high-demand applications, it's better to use the EJB 2.0 local interface or
to front the EJB with a traditional
JavaBean (some prefer a Session EJB) and pass that bean to an
updateAllProperties() business method in
the entity EJB. That lets you batch up the updates into a single RMI call."
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
