Wow, great reply, thanks for taking the time to explain all this. Above and beyond the call of duty! :)
--- Andrew Stevens <[EMAIL PROTECTED]> wrote: > On Mon, 2004-09-06 at 20:11, William I. Zumwalt > wrote: > > When I did ejb's by hand, I had three files ... > > > > MyRemote.java > > MyHome.java > > MyBean.java > > > > ... now using xdoclet, I have 6, > > > > My.java > > MyBMP.java > > MyData.java > > MyHome.java > > MyLocalHome.java > > MyRemote.java. > > > > ... and that's not including the MyPK.java which > I'm > > trying to get working ... so I'm thoroughly > confused. > > Why all these files? Where can I read up on all > these > > files cause I don't see any of this in the ejb > books I > > have. > > XDoclet lets you write beans that just contain your > business logic (the > interesting bits you care about) from the various > lifecycle methods > mandated by the spec (boring bits you don't care > about so long as they > work ;-)) To facilitate this, you create an > abstract bean class, then > it creates a subclass adding in the rest - this > would be MyBMP, MyCMP or > MySession depending on whether you're looking at a > session EJB, a BMP > entity EJB or a CMP entity EJB (there may even be > another one for > message driven beans, but I've not tried one > recently). > > The remote & home interfaces you're already familiar > with. MyLocalHome > and MyLocal are local equivalents (called directly > without the overheads > of marshalling & unmarshalling remote calls "over > the wire") that were > introduced with EJB 2.0. > > MyData relates to entity EJBs only and is a state > holder, a.k.a. Data > Object, a.k.a. Data Transfer Object, a.k.a. Value > Object (though XDoclet > also has a more flexible version of this which would > be called > MyValueObject). Instead of making many calls to an > entity EJB to set > various fields (which has a high overhead, > especially with remote > interfaces) you can make one call that returns an > object containing all > the fields' values, make the changes in that local > copy, then make one > call to write all the changes back to the EJB. Two > network round trips > instead of many. Of course, with local interfaces > this isn't such a > problem, but DTOs are still a useful pattern e.g. > for passing the values > between the EJB & web tiers of you application. > > MyPK is only needed if you have a composite primary > key for your EJB. > It's a javabean, similar to the MyData object, but > containing just the > key fields. If your EJBs only have a single primary > key field, then you > should specify that with the @ejb.bean primkey-field > parameter instead, > and you don't need to generate a PK class. > > If you're using BMP entity EJBs, there may also be a > DAO (data access > object, not to be confused with the data object > above) that lets you > separate out all the JDBC stuff from the EJB itself > (which it does as an > interface, allowing you to plug in different > implementations at runtime > in case you need different code for specific > databases). > > > And I have a questions a bit offtopic from the > above. > > I've seen so many examples of people making their > ejb > > abstract. How is that used? Do you treat it any > > differetnly than a normal abstract class, meaning, > > something other than derive another ejb from it? > Yes, > > I'm not very experienced w/ ejb's. > > There's two possible questions there, depending on > what exactly you mean > by "abstract". > > With CMP entity beans, you have to declare the class > abstract anyway as > all the getter & setter methods must (per the spec) > be abstract as the > container will implement them. With XDoclet, > because it will generate a > subclass (which is specified as the "implementation > class" in the DD) > for the lifecycle methods, you can declare your bean > class abstract for > the other beans types too. > > However, with entity beans, you might have a > (conceptually) abstract > "bean" from which you derive others e.g. an > "abstract" AnimalBean, and > "concrete" PenguinBean & DragonBean that derive from > it. With CMP, even > those subclasses would be abstract classes, but > you'd lookup instances > of them. The AnimalBean may or may not be truly > abstract depending on > whether or not looking up an AnimalBean instance > (which might be either) > is required or meaningful. That would determine > whether you'd also want > to generate the various classes for AnimalBean too, > or just use it as a > base class for your PenguinBean and DragonBean to > extend. Inheritance > of EJBs soon gets complicated, though, since you > have to worry about > whether the home/remote/pk/etc. also inherit from > the Animal ones and > whether there should be inherited finders in the > home interfaces that > take an AnimalPK etc. And a bunch of similar > issues. At this point, > people usually give up and switch from entity EJBs > to Hibernate or some > other Object-Relational Mapping tool instead. It's > bad enough coping > with O-R mismatch problems without having to worry > about half a dozen > related classes/interfaces as well... > > > Any help much appreciated. > > I suspect you're now twice as confused as when I > started. Sorry! > > > Andrew. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic > Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 > today. > http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click > _______________________________________________ > xdoclet-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-user > __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047&alloc_id=10808&op=click _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
