At 01:22 PM 9/22/99 -0700, Rajesh Save wrote:
>Hi,
>
>I recently joined the list and have found a lot of good tips already.
>
>I have a question about JavaBeans design and I dared to bring it up in the JSP
>forum as I think it is related. (BTW, is there any exclusive JavaBean
>discussion forum ?)
>
>I have got an impression (from books etc) that an ideal JavaBean should have a
>few properties (along with their get/set methods), and allow adding/removing
>EventListoners for other beans interested in those properties. That's all. It
>should not have any other methods as it will prevent others from using it just
>by plugging it under BeanBox.
In my experience, that is a pretty good design guideline for JavaBeans in
this context. When JavaBeans are used within JSPs, their role is similar to
Widgets in traditional GUI applications. Well designed Widgets have a few
properties and events, but in general don't contain utility methods or any
type of business logic in the Bean. You may also want to have JavaBeans
that are used to encapsulate business logic that will run in the Servlet.
The design principles for these Beans will be less like Widgets -- they
would typically have methods that implement business rules, etc, along with
properties to hold state.
>I am writing a JSP/JavaBean application, where a Bean is used to do handle
>Database. Assume there are 5 input fields on the WEB page and so there are 5
>corrosponding properties in the bean. From JSP, I can manage to set those
>properties individually using either "jsp:setProperty" or "<% mybean.setXxxx
>(yyy) %>". My question is, now how does the Bean know (or how do I notify it),
>that it's time to write the data in to the Database. I can have a method
>"storeInDatabase ()" defined in Bean and have it called, but I think
>that's not
>a correct design.
Actually, a method like "storeInDatabase ()" might not be a bad option for
what you're doing. You need to have a well defined model of how you will
handle your transactions in the Servlet. This includes both DB
transactions, and the transactional nature of the user's interaction with
your app. Let's say, for instance, that you have a button on your HTML form
that says "purchase all items in shopping cart." You will want to do all
the processing for that operation as one transaction, both from the users
point of view and for the database. To implement the transaction, you would
need to begin the Xact, call "storeInDatabase ()" for all the objects that
need to have their state saved, and then commit the Xact.
A good alternative might be to use an "persistence" layer, that is
implemented using EJB Entity Beans. Most "persistence" products have a well
defined model for dealing with the issues you're asking about, and using
one of them can save an awful lot of coding. That would leave more of your
time free to implement the business logic for your app.
Thanks, -Mark
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
