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]
