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
