Hi!
I fully agree with your opinion.
We in our company have decided to use ONLY stateful session beans(SSB) for
database access. Yes, it is necessary to create some proprietary persistence
stuff, but we see a lot of benefit from it mainly because there is only one
instance of SSB per database table (or more tables) for each user. Each
finder or query request for database row (also create, delete,..) results
only in changing state in appropriate SSB. This solution is very simple.
For me the question is why to have separate instances of Entity beans for
each database row. All methods are the same for all rows, aren't they? What
is changing are the fields. So the same effect could be achieved through
changing the state in one instance of session bean which represents one
entity (database table,...). Yes, I know that one instance of entity bean
can serve many users, but to implement simple task like - FOR EACH Item:
Item.price = Item.price + 10. END. - through some collections of thousands
or million remote objects is for me inacceptable.
Regards
Petr
----- Original Message -----
From: Johan Lundberg <[EMAIL PROTECTED]>
To: Orion-Interest <[EMAIL PROTECTED]>
Sent: Tuesday, March 20, 2001 8:22 AM
Subject: Why Entity EJBs?
> Hi
>
> The more I study the J2EE technology, the more I
> wonder why I should use it.
>
> The main reasons why I would use it are these:
> - Forget about the database layer while only using CMP
> entity beans.
> - Faster.
> - Scalable.
> - Easier to manage transactions.
> - Clear separation between client-workflow-persistence
> (JSP - Session beans - Entity beans).
>
>
> In our current system we use simple JSP, JavaBeans and
> a few connections to our database.
> We have made a few mistakes but we envisage cleaning
> up the system by starting from scratch. It is
> important that we choose the right technology but I
> get more and more sceptical about the EJB technology.
>
> We have experienced, when doing listings from a search
> page, that reading from the database and instantiating
> a few beans (not EJBs) takes a long time. The fastest
> way is to loop the resultset in the JSP-page, but it
> does have a few drawbacks and I would prefer to use
> another architecture.
>
> I thought that the pooled entity beans would speed up
> the system and started to study EJB.
>
> Then, Richard Monson-Haefel states in his book that
> listings shall be done directly between the Session
> bean and the database. Otherwise it would be too slow.
> I don't want to bother with SQL anymore and I would
> like to forget about the database layer, but it seems
> very difficult to get away with this requirement.
>
> To communicate between the JSP, the Session beans and
> the Entity beans, I get advised to use Data Access
> Objects. If I were to ignore the Monson-Haefel advise
> I would first create a bunch of Entity beans from a
> finder method, instantiate a collection of DAOs and
> send them back to the requesting Session bean. I
> wonder what kind of performance I would get from this
> system? I guess that this can become very heavy
> weight.
> It will probably become even more heavy weight when
> n-m OR-mapping becomes available.
>
> This will force us into a solution were we would have
> to use clusters and the scalability features of EJB
> comes handy. Is this the strategy from Sun - to make
> us buy more SUN servers?
>
> Now, what did I miss? Is there something that I have
> completely misunderstood? Please tell me what strategy
> we should use while developing CMP entity beans with
> Orion's OR-mapping features.
>
> I have found that another paradigm and framework that
> will simplify the development and reduce the amount of
> SQL-coding.
>
> http://jrf.sourceforge.net/ejb.html
>
> http://jrf.sourceforge.net/
>
> Why shouldn't we use this framework?
>
> Best regards
>
> /johan
>
>
> _____________________________________________________
> Do You Yahoo!?
> [EMAIL PROTECTED] - skaffa en gratis mailadress på http://mail.yahoo.se
