Other ApplicationsStruts Resume
Set your name in
Part I: Creating new DAOs and Objects in AppFuse - A HowTo for creating Java Objects (that represent tables) and creating Java classes to persist those objects in the database.
About this tutorialThis tutorial will show you how to create a new table in the database, and how the create Java code to access this table.
We will create an object and then some more classes to persist (save/retrieve/delete) that object from the database. In Java speak, we call the object a Plain Old Java Object (a.k.a. a POJO). This object basically represents a database table. The other classes will be:
[mysqld] default-table-type=innodb default-character-set=utf8If you're using PostgreSQL and you get confusing errors about batch processing, try turning it off by adding <prop key="hibernate.jdbc.batch_size">0</prop> to your src/dao/**/hibernate/applicationContext-hibernate.xml file.
AppFuse uses Hibernate for its default persistence layer. Hibernate is an Object/Relational (O/R) Framework that allows you to relate your Java Objects to database tables. It allows you to very easily perform CRUD (Create, Retrieve, Update, Delete) on your objects.
Font Conventions (work in progress)
Let's get started on creating a new Object, DAO and Test in AppFuse's project structure.
Table of Contents
Create a new Object and add XDoclet tags [#1]
The first thing we need to do is create an object to persist. Let's create a simple "Person" object (in the src/dao/**/model directory) that has an id, a firstName and a lastName (as properties).
This class should extend BaseObject, which has 3 abstract methods: (equals(), hashCode() and toString()) that you will need to implement in the Person class. The first two are required by Hibernate. The easiest way to do this is using Commonclipse. More information on using this tool can be found on Lee Grey's site. Another Eclipse Plugin you can use is Commons4E. I haven't used it, so I can't comment on its functionality.
Now that we have this POJO created, we need to add XDoclet tags to generate the Hibernate mapping file. This mapping file is used by Hibernate to map objects → tables and properties (variables) → columns.
First of all, we add a @hibernate.class tag that tells Hibernate what table this object relates to:
We also have to add a primary key mapping or XDoclet will puke when generating the mapping file. Note that all @hibernate.* tags should be placed in the getters' Javadocs of your POJOs.
Create a new database table from the object using Ant [#2]At this point, you can create the person table by running ant setup-db. This task creates the Person.hbm.xml file and creates a database table called "person". From the ant console, you can see the table schema the Hibernate creates for you:
[schemaexport] create table person ( [schemaexport] id bigint not null, [schemaexport] primary key (id) [schemaexport] );
If you want to look at the Person.hbm.xml file that Hibernate generates for you, look in the build/dao/gen/**/model directory. Here's the contents of Person.hbm.xml (so far):
Now we'll add additional @hibernate.property tags for our other columns (first_name, last_name):
In this example, the only reason for adding the column attribute is because the column name is different from our property name. If they're the same, you don't need to specify the column attribute. See the @hibernate.property reference for other attributes you can specify for this tag.
Run ant setup-db again to get the additional columns added to your table.
[schemaexport] create table person ( [schemaexport] id bigint not null, [schemaexport] first_name varchar(50), [schemaexport] last_name varchar(50), [schemaexport] primary key (id) [schemaexport] );
If you want to change the size of your columns, modify the length attribute in your @hibernate.property tag. If you want to make it a required field (NOT NULL), add not-null="true".
Create a new DaoTest to run JUnit tests on your DAO [#3]
The AppGen Tool
As part of 1.6.1, I created an AppGen tool that can be used to generate all the classes for the rest of these tutorials. This tool was based on contributions from Lance Lavandowska and Ben Gill. At first, I didn't want to add a code-generation feature like this b/c you'd end up with a 1-to-1 relationship between tables/pojos, DAOs and Managers. On most of my projects, I have far fewer DAOs and Managers than POJOs.
By default, AppGen will generate only Actions/Controllers, Action/Controller Tests, test data, i18n keys and JSPs. It will also configure Actions/Controllers for you. It uses the generic BaseManager and BaseDaoHibernate classes (configured as "manager" and "dao") to reduce the number of files that are generated. However, I realize that sometimes you will want to generate all the DAO and Manager classes (as well as their tests), so I've added that option too.
To use the AppGen tool (after installing your web framework), perform the following steps:
The reason for the "lowercase" parameter is to rename the JSPs to begin with a lowercase letter. If I tried to rename them and change the filename programmatically, it took 1MB worth of BSF and Rhino JARs (+5 lines of code) and this just seemed easier. Speaking of JSPs - it's up to you to modify the *Form.jsp and make it look pretty. This is covered in Step 5 of each respective web framework's "Create Action/Controller" tutorial: Struts, Spring and WebWork.
NOTE: If you'd like to generate all the DAOs/Managers/Tests, run ant install-detailed instead of ant install. Before you install anything, the files will be created in the extras/appgen/build/gen directory (in case you want to look at them before installing). If you just want to test the tool, you can cd to this directory and run ant test to see the contents of these tutorials created.
I encourage you to read these tutorials even if you decide to generate all your code. That way you'll understand what's being generated for you and you'll only need to mailing list for asking smart questions. ;-) Hopefully this tool will remove the pain of writing simple CRUD code and let you concentrate on developing your business logic and fancy UIs!
Now we'll create a DaoTest to test that our DAO works. "Wait a minute," you say, "we haven't created a DAO!" You are correct. However, I've found that Test-Driven Development breeds higher quality software. For years, I thought write your test before your class was hogwash. It just seemed stupid. Then I tried it and I found that it works great. The only reason I do all this test-driven stuff now is because I've found it rapidly speeds up the process of software development.
To start, create a PersonDaoTest.java class in the test/dao/**/dao directory. This class should extend BaseDaoTestCase, which already exists in this package. This parent class is used to load Spring's ApplicationContext (since Spring binds the layers together), and for (optionally) loading a .properties file (ResourceBundle) that has the same name as your *Test.class. In this example, if you put a PersonDaoTest.properties file in the same directory as PersonDaoTest.java, this file's properties will be available via an "rb" variable.
The code you see above is what we need for a basic JUnit test that initializes and destroys our PersonDao. The "ctx" object is a reference to Spring's ApplicationContext, which is initialized in a static block of the BaseDaoTestCase's class.
Now we need to actually test that the CRUD (create, retrieve, update, delete) methods work in our DAO. To do this we created methods that begin with "test" (all lower case). As long as these methods are public, have a void return type and take no arguments, they will be called by our <junit> task in our Ant build.xml file. Here's some simple tests for testing CRUD. An important thing to remember is that each method (also known as a test), should be autonomous. Add the following methods to your PersonDaoTest.java file:
<table name='person'> <column>id</column> <column>first_name</column> <column>last_name</column> <row> <value>1</value> <value>Matt</value> <value>Raible</value> </row> </table>
In the above example, you can see that we're calling person.set*(value) to populate our object before saving it. This is easy in this example, but it could get quite cumbersome if we're persisting an object with 10 required fields (not-null="true"). This is why I created the ResourceBundle in the BaseDaoTestCase. Simply create a PersonDaoTest.properties file in the same directory as the PersonDaoTest.java file and define your property values inside it:
firstName=Matt lastName=RaibleThen, rather than calling person.set* to populate your objects, you can use the BaseDaoTestCase.populate(java.lang.Object) method:
At this point, the PersonDaoTest class won't compile yet because there is no PersonDao.class in our classpath, we need to create it. PersonDAO.java is an interface, and PersonDAOHibernate.java is the Hibernate implementation of that interface. Let's go ahead and create those.
Create a new DAO to perform CRUD on the object [#4]First off, create a PersonDao.java interface in the src/dao/**/dao directory and specify the basic CRUD methods for any implementation classes. I've eliminated the JavaDocs in the class below for display purposes.
Notice in the class above there are no exceptions on the method signatures. This is due to the power of Spring and how it wraps Exceptions with RuntimeExceptions. At this point, you should be able to compile all the source in src/dao and test/dao using "ant compile-dao". However, if you try to run "ant test-dao -Dtestcase=PersonDao", you will get an error: No bean named 'personDao' is defined. This is an error message from Spring - indicating that we need to specify a bean named personDAO in applicationContext-hibernate.xml. Before we do that, we need to create the PersonDao implementation class.
Let's start by creating a PersonDaoHibernate class that implements the methods in PersonDao and uses Hibernate to get/save/delete the Person object. To do this, create a new class in src/dao/**/dao/hibernate and name it PersonDAOHibernate.java. It should extend BaseDaoHibernate and implement PersonDAO. Javadocs eliminated for brevity.
Now, if you try to run ant test-dao -Dtestcase=PersonDao, you will get the same error. We need to configure Spring so it knows that PersonDaoHibernate is the implementation of PersonDAO, and we also need to tell it about the Person object.
Configure Spring for the Person object and PersonDao [#5]
First, we need to tell Spring where the Hibernate mapping file is located. To do this, open src/dao/**/dao/hibernate/applicationContext-hibernate.xml and add Person.hbm.xml to the following code block.
Now we need to add some XML to this file to bind PersonDaoHibernate to PersonDao. To do this, add the following at the bottom of the file:
Run the DaoTest [#6]Save all your edited files and try running ant test-dao -Dtestcase=PersonDao one more time.
Yeah Baby, Yeah:
Next Up: Part II: Creating new Managers - A HowTo for creating Business Facades, which are similar to Session Facades, but don't use EJBs. These facades are used to provide communication from the front-end to the DAO layer.