Oh man, this is so cool. And your info was of great help. Especially mentioning the reasons for passing around EJB's themselves over DTO's. And I think I'll hold off on the VO's given those facts.
Thanks for the write up. --- Andrew Stevens <[EMAIL PROTECTED]> wrote: > On Mon, 2004-09-27 at 19:38, William I. Zumwalt > wrote: > > I'm trying to implement a DAO pattern in my > enitities > > (first time) and I understand them, but what I'm > not > > understanding is how to do them w/ XDoclet. I > think > > basically I just need to create an interface for > my > > DAO, and then the DAO implementation class. But I > have > > no clue on how to use the few dao attribs I found > in > > the docs. I did put the following in the top of my > > entity bean along w/ the proper build.xml > > <dataobject/> tag. But havn't noticed anything > from > > it. > > > > * @ejb.dao > > * class="com.blah.blah.DeviceDAO" > > * > > Wrong subtask - you should use <dao> in order to > generate the DAO > interfaces, and it's only really of use with BMP > entity beans (as CMP > beans will use container-generated data access > methods). In some > circumstances you might want to use them with > session beans too, if they > access the database directly rather than going via > entity beans, and the > subtask allows for this. > http://xdoclet.sourceforge.net/xdoclet/ant/xdoclet/modules/ejb/dao/DaoSubTask.html > > > I especially got lost in how to define the body of > my > > DAO methods when it hasn't been generated yet. > > Easiest thing is to run the subtask once in order to > generate the > interfaces (most stuff is automatic once you've got > and @ejb.dao tag and > the <dao> subtask), then use your preferred IDE to > create classes that > implement those interfaces. Then tailor the > @ejb.dao tags according to > your preferred method of instantiating those > implementation classes. > > If you've used the class parameter on your @ejb.dao > tag then that's the > classname the interface should be generated with, > otherwise it's > calculated from the package and pattern parameters > if present, or > default values otherwise (which I don't remember > offhand, possibly > FoobarEJB => FoobarDAO in the same package?) > > The generated interfaces automatically include > equivalent methods for an > entity EJB's create/load/store/remove/finder > methods, and the generated > BMP subclass will call them. The DAOs also include > methods for any bean > methods you tag with @dao.call, and again the > generated BMP/Session > subclass will delegate to them. > > > If it's any help as to what I'm doing, almost > exactly > > the following ... > > > http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html > > The main difference from the stuff in Sun's pattern > is that there's no > DAOFactory (although there's an open enhancement > request to cater for > one). Instead the BMP/Session generated subtask > will contain a getDao() > method, which creates an instance of your > implementation class according > to the parameters on your @ejb.dao tag. If you have > a > impl-class="FooImpl" parameter, it just uses > FooDAO dao = (FooDAO) new FooImpl(); > so only use this parameter if you don't need to > switch in an alternative > implementation class at runtime (e.g. you only use > one DBMS). If you > use impl-jndi="FooImpl", it does a JNDI lookup for > java:comp/env/FooImpl > and creates an instance of the class whose name is > in that environment > reference. This lets you swap in different classes > by changing your > EJB's properties on deployment, or later via the > container's tools. > > The other difference between Sun's pattern and our > generated code is > that rather than using Data Transfer Objects (see > below) to pass the > fields' values around between the EJB and DAO, we > just have the EJB pass > a reference to itself to the DAO; your DAO Impl > classes can then use > that reference to call the fields' getters & setters > as necessary. > > Also, I don't know what database you're using or how > you're connecting > to it, but one other things possibly worth > mentioning is that since the > DAOs are called from the EJB's lifecycle methods > it's possible for them > to do a JNDI lookup for the EJB's DataSource > resource references. > > > Also, is the *Data.java file that xdoclet > generates (I > > think because of the <dataobject/> tag and writes > > "Data object for ..." in the top of the file > content > > ... does data object also mean "Transfer Object" > in a > > DAO pattern sense? Same thing? Is that what got > > generated? Looks like it to me. > > The short answer is "yes". > > <dataobject> generates Data Transfer Objects a.k.a. > Data Objects a.k.a. > Value Objects, which are a pattern in themselves - a > state holder class > for passing around between layers & for minimising > the number of remote > calls being made. Not to be confused with the Data > Access Objects, > which are to do with delegating the access to the > persistent data store. > > Just to confuse things further ;-) there's a > <valueobject> subtask, > which is a more flexible version of the DTO pattern. > It was developed > after the <dataobject> (and was intended to > supercede it) and allows for > multiple VOs containing subsets of the fields in a > bean, and handles > relationships between beans e.g. an OrderVO might > include all the order > lines' state as well. However, other generated code > still uses the > original DataObjects, so we haven't managed to kill > them off yet. Plus, > setting up the VOs can be a bit trickier, especially > the relation bits. > > You may still want to use both DAO and DTO patterns > in your beans, but > the XDoclet DAOs don't require the use of > <dataobject>. > > > Andrew. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: YOU BE THE JUDGE. > Be one of 170 > Project Admins to receive an Apple iPod Mini FREE > for your judgement on > who ports your project to Linux PPC the best. > Sponsored by IBM. > Deadline: Sept. 24. Go here: > http://sf.net/ppc_contest.php > _______________________________________________ > xdoclet-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/xdoclet-user > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
