I think the confusion arises where people people assume EJB's were designed for object persistance.
They weren't, and in fact the persistance stuff was probably added more as an afterthought than anything. The technology emerged at the time where distributed object frameworks like CORBA and DCOM were getting trendy. Java already had RMI, but Microsoft was adding MTS features to DCOM and CORBA had all those bolt on services. Hence the java community received EJB, the java equivalent of the fusion of ideas that were being developed at the time. EJB's were *never* designed for fine grained access to a relational database. The vision of a EJB was a server side component that behaved in an object oriented way, but had clever things like pooling and transactions thrown at it so that the server could potentially handle millions of concurrent users. However, as CMP was the only standard that offered a way of doing O/R mapping, naturally a lot of people started using it for this job. Now we have JDO which is a technology specifically designed to map between java code and persistence engines. It doesn't do anything else. That makes it potentially much more efficient at the job and enables java programmers more freedom with things like inheritance. So why use JDO's? They are lightweight, they are designed for the problem you are trying to solve, they have an AOP like philosophy and the integrate nicely with OO inheritance. I struggled with this question for some time and tried to find reasons why *not* to use JDO over CMP, but I couldn't find any. Unless of course you consider that JDO is not yet as mature as CMP and the open source projects supporting JDO are still a little thin on the ground. On Thu, 2003-07-03 at 08:27, Ionel Gardais wrote: > Hi, > > I was already wondering why to use JDO when someone is already using > EJBs. This feature confuses me more ! > Make a POJO persistant archieve the same goal as an Entity bean ? so why > bother : I do not see any other advantages than the speed of > developpement (no EJB overhead, just POJO). > > Back to a more technical question : to make something persistent, you > should define a way to store it in a secure place. To work at a field > level (for the queries for example), you should store the object's > fields in an independant way. > Question is : what storage layer to use and where to declare all this > (fields mapping and relative stuff)? > > I guess a database is the layer and a config file does the mapping (the > page that is still under construction) but (database + mapping > configuration files) = ejb ... > > > Ionel > > > > ------------------------------------------------------- > This SF.Net email sponsored by: Free pre-built ASP.NET sites including > Data Reports, E-commerce, Portals, and Forums are available now. > Download today and enter to win an XBOX or Visual Studio .NET. > http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 > _______________________________________________ > JBoss-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-user -- Peter Beck BEng (hons) MIEE - Managing Director, Electrostrata Ltd. http://www.electrostrata.com --+-+-- Experts in e-business and e-commerce ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
