I have one question that's been bothering me for so long.
I have this listing function which returns a tabular data. Each row actually
represents a
subset/all attributes of an entity bean. The columns shown depends on the user
setting.
The user can also select which column to use for sorting the results. Lastly, the user
can set how many rows are shown per page. Currently, I've designed it using session
bean
that directly access the database. Which one should I use direct JDBC access to the
database or use entity bean instead? By the way, is it possible to implement this
behavior in entity bean? Another question, can I implement something like sort by XXX
field in findByYYY method of EJBHome?
thanks in advance....
Jerson
--- MARK HAPNER <[EMAIL PROTECTED]> wrote:
> Purushotham Das K wrote:
> >
> > hi folks,
> >
> > I am in a dilemma whether to go for JDBC from the session bean
> > directly or use an entity bean for querying the database . Can some one tell
> > me which I should use and when should i go for either of them and also which
> > will be more efficient performance-wise.
> >
> > Thanks in advance
> > Purush
> >
> > ===========================================================================
> > 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".
>
> Purushotham,
>
> Both alternatives work.
>
> One of the major reasons for using the entity bean alternative is to
> provide a more formal entity 'tier' as a service rather than as a
> library of data access objects. One of the benefits of having a more
> formal entity service tier is that it factors this into a shared service
> that can be independently administered rather than proliferating
> multiple copies of a DAO library hidden away in several applications.
>
> Adding an EJB entity 'tier' does add some overhead for container
> management; however, this is smaller than many people think.
>
> As for the query issue that was raised in this thread, it is true that
> any solution that iterates across large numbers of entities will likely
> be inefficient; however, there is no need to implement queries this way.
> Queries should be implemented by the entity tier itself and use the
> underlying services of the database directly.
>
> If aggregate information needs to be returned, this should be
> implemented as an aggregate information service which is part of the
> tier. One way to do this is to implement it as a Session EJB that is a
> partner of its Entity EJB and shares the same underlying database
> schema. Together they provide an efficient abstraction of the entity
> tier. In EJB 2.0, the aggregate service can be implemented as Home
> methods on the entity (which simplifies this pattern somewhat).
>
> -- Mark
>
> ===========================================================================
> 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".
>
__________________________________________________
Do You Yahoo!?
Yahoo! Mail � Free email you can access from anywhere!
http://mail.yahoo.com/
===========================================================================
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".
