This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I have read that direct replication of the relational model with entity beans is bad practice. Good practice is to reduce inter entity bean communication and to create coarse grained entity beans. I am using EJB2.x specification - CMP and CMR to model my business data. It seems a natural thing to simply replicate the existing relational model with entity beans. Why is this such bad practice. How should I go about this in practice?? Thank you.
Originally posted by Kelly Walker II: I have read that direct replication of the relational model with entity beans is bad practice. Good practice is to reduce inter entity bean communication and to create coarse grained entity beans.
This was definitely true with regards to EJB 1.1. However EJB 2.0 is a large step forward and this best practice does not really hold true now that we have things like local interfaces, CMP 2.0, and CMR. However, the current trend of best practices is to not use Entity Beans at all.
Joined: Sep 09, 2003
So are you saying that CMP and CMR are a bad thing? How then should I create, update, delete, select data from my RDBMS. Do you advocate using only session beans and direct JDBC calls? Or did I muisunderstand?
Joined: Jul 18, 2001
First off, since I don't know anything about your application, it is not clear that you need EJB at all. Assuming that you are using EJB... I prefer to go with Session Bean + Hibernate (or plain JDBC if it is a simple application) over Entity Beans. [ September 09, 2003: Message edited by: Chris Mathews ]
Sticking with just the J2EE specification, are you saying that I should give entity beans a wide berth? I use weblogic 8.1 btw.
Joined: Jul 18, 2001
Originally posted by Pradeep Bhat: Does it mean that it is not free?
No it is definitely free, however it is good to know what license you will have to abide by. For example, LGPL is less restraining than the standard GPL but still not as flexible as BSD or ASF licenses.