General J2EE: Database design and EJB's
- Posted by: Justin MacCc
- Posted on: September 29 2002 16:51 EDT
I'm new to EJB, and coming from a Database centric programming. It seems to that with EJB2+ and CMP/CMR that you basically forget about the SQL, is that correct? You just map your Beans to fields, and let the container to the work?
Is this the case? Is this really scaleable ?
That's right. You can have EntityBeans that match an object model and make sense from the perspective of the business domain. It's easy to get attributes from different data sources, switch out databases, etc. For performance increases, use caching of EntityBeans whenever possible and watch out for big joins (as always).
It seems to that with EJB2+ and CMP/CMR that you basically forget about the SQL, is that correct? You just map your Beans to fields, and let the container to the work?
a-ha, dream on, my friend! I'm 3 years in EJB business. There's no way to forget about SQL unless you are doing a fake classroom projects.
and yes, it's not scalabale.
I am responding to the following claim:
"... it's not scalabale."
I would appreciate it if you could explain both what specifically doesn't scale and what lessons you have learned. I am a newbie and I would love to hear any war stories you might want to share.
No it is not scalable at all....
It is very easy to misuse Entity Beans, or do mistakes with them. Imagine using a finder methods - if you finder method returns 2000 records, doesn't it effectively means that app server will try to create 2000 entity beans ? Correct me if i am wrong here.
It is all good theory to use Entity Beans especially CMP entity beans.
The only thing they seem to do well is - provide very good caching in case u use - read only entity beans (weblogic provides a way to do this..not sure if it is a standard.).
I have very often come across EJB based projects where entity beans were present in the design stage of the project, but as it proceeds, people drop them, and simply go with Stateless Session Beans.