Hi Arunmozhi,
[-- cross-posting to [EMAIL PROTECTED] list since the contents
are relevant there as well --]
> I am looking for some design guidelines for creating business object EJBs.
>
> 1. Should I have business logic in entity beans ?
IMHO, it makes sense to have two types of business logic in session
beans (typically, stateless session beans):
1. Operations involving multiple rows in a database: Entity beans seem
more appropriate for single row
operations. Moreover, it may be more efficient to do multiple row
operations in session bean.
2. Shared Service Object: The object implements a service (e.g.,a mail
service) and it needs to be
shared across remote objects. e.g., In an ecommerce application, you may
want to send order
confirmation mails to the customers on successful completion of orders.
This is a service, and it may
need to be shared all over the application(for centralized logging,
etc.)
> 2. Should they just implement the insert/update/delete into
> the corresponding table ?
> 3. As per the business logic, If an update/insert/delete
> operation on a table requires updating/inserting/deleting
> on a different table as well - where this logic should be coded ?
> 4. Should session beans be used for implemnting this busiiness logic ?
If you can handle it by a "join", then it makes sense to do this in an
entity bean. Otherwise, session bean seem more appropriate.
> 5. Should there be one instance of session bean for each instance
> of corresponding entity bean ?
> 6. Should session beans be used to wrap Entity beans ? If yes,
> what should be the criteria for selecting the entity
> beans that needs wrapping ?
(I assume that you mean stateful session beans here).
Since session beans are used to implement current session specific
functionality and entity beans are used to implement data objects in
your system, having a stateful session bean for each entity bean will
probably not even make sense in most cases. However, this approach may
be useful to personalize the generic data coming out of the entity bean
to the current client session.
> 7. Should I have one session bean for one UI screen ?
This seems like an interesting approach when using Model-View-Controller
pattern to architect your application. MVC recommends one controller per
view. So, if each of the UI screen is actually a different
view, then you should have a controller (implemented as a session bean)
per UI screen.
However, typically, your view will consist of multiple screens, so you
should logically group them together and have a single controller for
them.
comments welcome
thanks
inder
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
