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".
