>From reading this, it seems author is interested in promoting an
architecture designed to eliminate the advantages of object oriented
development and make maintenace a hair-pulling experience.
Combining the FOrm bean, MOdel, and COntroller components together results
in what I'll call a FoMoCo bean - or as the author says, "a model that
incorporates dispatcher and view characteristics". Like I said, FoMoCo.
The FoMoCo bean approach has two major drawbacks.
- Maintenance of the application becomes much more difficult with a
greater liklihood of bugs being created.
- Building a large application with multiple developers becomes much more
difficult as it is impossible to break the different layers apart for
different people to work on.
For example, imagine you are building an application and the database
schema is changed. Several tables are reorganized, but the data is similar.
Imagine this data is desplayed on several pages in the app. Or imagine
you've found data problems and need to add code to catch bad data if it
comes. Here's the impact:
- Using Struts as it is designed, you would do the following:
- Modify the Model components (Entity EJB's or DAO objects if
you're not using EJB's) to reflect the new queries/code required to get the
data.
- Make no changes to how you populate the form beans in the
action servlets. The changes have been isolated into the data access layer.
- The presentation layer is untouched. None of the pages/form
beans using the data need to be updated.
- In summary: Change DAO or EJB, Don't change controller, form
bean or jsp for any of the pages using the data.
- In FoMoCo, you'd do the following:
- Go into each FoMoCo bean on every page needing the data, and
modify the code in each.
- Since the code in each FoMoCo bean has set/get properties, JDBC
code and/or EJB calls the changes may be complicated.
- This spreads the changes through more class files - that are
each more complex and prone to bug creation.
- Since the FoMoCo's may have been written by different people,
it's difficult (and error prone) figuring out every place that needs to be
changed.
FoMoCo eliminates all the benefits of good object-oriented design.
In addition, the author's approach of packaging the persistance mechanism
in the form bean is misguided at best. This means you'll have to use the
same form bean on every page requiring access to the persistence mechanism.
(i.e., every page in your app potentially). Please seperate this logic out
of the form bean and put it in a User bean (or something similar) that is
stored on the session context.
Calling this approach to managing persistency "controversial" is
appropriate. It's controversial like recommending a sick person be given "a
good bleeding".
One thing the author did accomplish, however, was his stated goal to "
further cloud the issue".
FWIW -
Kevin
[EMAIL PROTECTED] on 04/16/2002 05:34:40 PM
Please respond to "Struts Users Mailing List"
<[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
cc:
Subject: Java Pro Article: Thought I have form beans figured out...
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]>
---------------------------------------------------------------------------
This e-mail message (including attachments, if any) is intended for the use
of the individual or entity to which it is addressed and may contain
information that is privileged, proprietary , confidential and exempt from
disclosure. If you are not the intended recipient, you are notified that
any dissemination, distribution or copying of this communication is
strictly prohibited. If you have received this communication in error,
please notify the sender and erase this e-mail message immediately.
---------------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
