What I understand is Entity Beans are a kind of wrapper on the relational database and present the data as objects. So in our code we will be dealing with these objects and not with database directly. But adding one more layer will certainly hamper the performance. So using the Entity Beans will also decrease the performance.
Instead of using the Entity beans we can use SQL from our Session Bean to access database directly (rather than going through a layer). And since allmost all the programmer have good knowledge of SQL it shouldn't be a problem. And this will be more efficient than enity beans.
Then why should we use Entity Beans ?
I'm not a professional in EJB, but I hope I can anser the Question.
We have made a project where we had to change the DB-System from Oracle to DB2. If you want to do this you nearly must use Entity-Beans. If you only write ANSI-SQL it shouldn't be a Problem but we all know that every DB-System is different. So if you want to change the DB-System you only have to make a new mapping and thats it(realy?).
The aspect of the performance has to be handled differently. If you use the IBM Websphere you should reduce the Entity-Beans to the min. Bea's Weblogic can handle Entity-Beans much faster than IBM can, don't ask me why.
(a beginners anser) mfg Peda
Check out a few design patterns using Session Beans and JDBC -- one or two might be posted here at TheServerSide. Avoid entity bean usage, if possible. It really is unnecessary for most applications.
You can also check out the JDO (Java Data Objects) implementation at www.javasoft.com. JDO really is a much more seamless and sensical persistence framework than EJB.
I think it's not a good thing to consider, that Sun wasted a lot of money and time for including entity beans in their specification and there is no sense in them (not only Sun, dozens of container vendors wasted their time too ;) ). They have sense. JDO is nice thing, but both has a right to live, and, pls, take into consideration that JDO WILL be used in next implementations of entity beans and CMP/CMR. JDO is kind of assembly language - a mid between high-level language and machine code. Concerning JDBC and Session Beans pattern: who said that we are still working with RDBMS? What if we want to persist into object database or to some kind of legacy system? We need universality, entities provide it. Of course, that doesn't mean that you should use entities in your every project, but I think that if Sun will continue "wasting" money in entity beans, CMP/CMR and other companies will create nice tools and smart containers to handle them, you'll be one of the first guys who will say: "Hey, why I should mess with that SQL and session bean's code, if I can just click my mouse and <toolname> will do the same".
Currently, using entities is not the best way to achieve a good perfomance, but they still help you to think in object-oriented manner and to understand the future perspectives.
Believe me, Sun is not the first technology company to include 'not-so-well-thought-out' ideas in their specifications -- Microsoft has been doing it for years, as well. Its my opinion that entity beans in their current form are really not that efficient, nor scalable to most applications -- albeit completely unneeded.
You quote the word "wasting". I never said they "wasted" their time or money. On the contrary, Sun has spun their marketing to a new level with EJB and entity beans. They have gotten application server vendors to jump on board -- while abandoning their own proprietary technologies in the process (even if they were better than entity beans). A truly amazing feat.
Mark my words, with the new JDO specification, you will see more and more people jumping ship from entity beans -- and solely using JDO. Why? Because it is makes more sense -- especially within an object model. You say that JDO is like "assembly language" -- but I don't get the comparison. To me... JDO is a vast improvement over BMP/CMP beans without the performance issues.
I do believe that JDO should be open-source for all to share and contribute, but I can't have everything. I will acknowledge that JDO does seem to have given much more input from outside vendors than did with the original EJB specs. I think this is evident as JDO is much more in line with other more popular O-R mapping/persistence-framework tools. Very similar in nature.
BTW... if it becomes necessary to interface with a legacy store, then by all means, the right tool for the right job. But I'm saying that for most jobs -- entity beans are not the right tool -- even though they are the only Sun-accepted tool (except for JDO) for persistence... unfortunately.
In my experience with J2EE projects, I found entity beans usefull only under the following scenario
1. Maps complex business objects spanning multiple tables
AND / OR
2. The business objects are read only or read mostly.
Otherwise, I always used session beans with JDBC.
Another scenario when entity beans are useful is:
'Administration' module in your application. Application Administrators may want to modify data in the lookup tables (eg prices, discounts, etc, etc, etc...). The code is mostly quite simple (CRUD operations), you want it to be written quickly and performance requirements are not too high as there will be only a few users.
Entity beans are a 'quick and dirty' way to get the job done.
[This is my message co-opted from a patterns discusssion.]
This gets me re-thinking EJBs. Given some of the "issues" with entity beans (performance, bulk cacheing & optimistic locking "work arounds", clustering, vendor locking) my take is that entity beans degenerate to "expensive" DAOs.
From that, I go to EJBs degenerating to session beans + DAO. Which I am quite happy with since I *do* trust the database for reliability/clustering/cacheing/etc and I am then thankful for what *I* really want in EJB session beans --- easy-to-use transaction support.
*But* if I had a *really* nice pattern (or implementation) for easy-to-use transaction support, I would be happy with servlets/beans/JSP/JMS + txn support + standardized DAO (JDO?). No EJB. System would be faster and "lighter" without all those EJB layers. [Will checkout JDO@sun]