Rickard wrote:
> I would propose a slightly different model. Use EntityBeans, but
> DEFINITELY use "value objects". Then, place a facade session on top
> of your EntityBeans which the clients can access. This should
> return value objects if entity data is requested.
Thanks for your alternative perspective on this topic.
In jBoss, can EJB objects be read by many users at the same time? Weblogic
grabs (or used to grab) a pessimistic lock on entity beans during a simple
read operation. This was so odious that we got rid of all our entity beans.
I definitely agree with what you said about passing value objects around.
And your bean layering suggestion would definitely work for small to medium
sized applications.
I was just yesterday (Sunday) at the "EJB/J2EE for large scale development"
tutorial at OOPSLA that was given by Peter Herzum. He recommends *never*
using CMP that maps one bean to one table if you need your application to
scale (both for runtime and development), but instead have one bean map to a
minimum of 4-5 tables (10 is more common in his experience) that fit into a
logical grouping. The bean can be either a Session Bean or BMP (bean
managed persistence) Entity Bean. (I know this sounds harsh, but the more I
thought about it, the more I realized that it makes a lot of sense--and it
fits with our experience).
Another statement from Peter's presentation was that "Only the business
objects that need to be accessed directly by the client need to be
enterprise beans: Use helper objects". Accessing Entity beans from Session
beans creates the risk that a rogue programmer will access those entity
beans directly from the client instead of going through the session bean.
Granted, security can control this, but that's not really what security
should be used for.
Basically, we lost nothing (security, transactions, etc) when we flattened
out our EJB layers from three to one. What we gained was simpler, easier to
maintain code, and a tremendous improvement in performance.
Regards,
Jonathan Carlson
Minneapolis, Minnesota
http://www.is.com
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Rickard �berg
Sent: Saturday, October 14, 2000 4:26 AM
To: jBoss
Subject: Re: [jBoss-User] Is EJB the model for us ?
Hi!
Jonathan Carlson wrote:
> I wouldn't recommend accessing your entity beans directly from the client.
> In fact, I wouldn't even recommend using entity beans.
>
> We ended up passing data objects to/from session beans which stored or
> retrieved the data using a SQL framework (which we have open-sourced at
> http://jrf.sourceforge.net) The performance gains by using this instead
of
> container-managed entity beans were incredible and the framework allowed
us
> to get a lot of code reuse.
>
> What we gained was transactions, security, and the value of keeping the
> database access logic on the server.
I would propose a slightly different model. Use EntityBeans, but
DEFINITELY use "value objects". Then, place a facade session on top of
your EntityBeans which the clients can access. This should return value
objects if entity data is requested.
This way you minimize the RMI overhead, can use EntityBeans for
persistence and encapsulation, and have the option of later removing
EntityBean altogether and go with only value objects+JDBC.
Note that EntityBeans can give you *better* performance than JDBC in
some cases where you can rely on caching. Using either tuned updates or
the new isModified optimization gives you quite good performance on
read-only operations.
For minimal hassle I would recommend using code generation to do the
value objects. And of course I recommend using the EJBDoclet that I
released some time ago for this purpose:
http://www.dreambean.com/ejbdoclet.html
regards,
Rickard
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
