|
Database Views
Data is often read from a database using a view. A view is a SELECT statement joining several tables most often using a WHERE clause. It's absolutely legal to make a DAO that maps a view. Since a view cannot be used for updating a database, such a DAO will only contain finder-methods.
The Transaction Handler Layer
Having determined to use "DAO beans" to communicate with the DAO layer, it's now time to see how clients should communicate with the transaction handler layer. First of all, the API offered by the handlers should be useful to the clients. This means that method parameters should match the data the clients have at hand. Clients can be browser/Swing applications or Web services, but they may also be other transaction handlers. Therefore, expect the handlers to have several APIs available.
The picture now looks like this:
A DTO is often a mixture of data returned from more than one DAO bean, i.e. data held in several tables on the database. If you expand your "DVD business case" with a Director table, then you could create a client demand that fetched DVD information—including director data (name, birthday, other movies, etc.). Other clients might want only the title of a DVD; it's not difficult to imagine many client requests that differ only slightly in the amount of data they want returned.
Here's an example: suppose the DVD table contains a key to the Director table—should you return only the key? Or should you return some or all of the director data? And if the Director table has keys to other tables, when should you stop retrieving and returning data to the clients?
If you're not careful, you may end up with a lot of DTOs, all having a lot of properties in common, but without proper inheritance. There is no single, simple answer to how to cut your DTOs correctly, but there are some guidelines which have proven useful.
Using the Same Data Classes
You may be tempted to use the same data classes as transport to the handlers
and the DAOs. In simpler applications, or when handling simple requests, the
clients want exactly what's in the DAO beans. The downside to doing this is that
changes in a DAO&3151;and thus in the DAO bean—will be visible to the clients. To avoid tight bindings between the layers, only use the DAO beans as the interface to the DAOs.
You may have noticed, that in the previous articles about the DAO patterns, DAO
beans were also used as DTOs. This was done to keep the focus on the application layers, and not on the data transport.
Returning Only the Key
Some clients may only want the database key returned. Therefore, a good
idea is to define a Key class for the DTOs—and also for the DAO beans—and let all DTOs use this class (assuming, for simplicity, that all DTOs use the same key type).
package dk.hansen.dto;
public class Key_DTO {
private String id;
public Key_DTO() {}
public Key_DTO(String id) {
this.id =id;
}
public String getId() {return id;}
public void setId(String id) {this.id = id;}
}
Using the Key
The DTO with DVD information may now use Key_DTO:
package dk.hansen.dto;
public class DVDKey_DTO {
private Key_DTO key;
public Key_DTO getKey() {return key;}
public void setKey(Key_DTO key) {this.key = key;}
. . .
The smallest possible DVD DTO contains only one property besides the key:
package dk.hansen.dto;
public class DVDKeyValue_DTO extends DVDKey_DTO {
private String title;
public String getTitle() {return title;}
public void setTitle(String title) {this.title = title;}
public static void main(String[] args) {
DVDKeyValue_DTO dvd = new DVDKeyValue_DTO();
dvd.setKey(new Key_DTO("12"));
dvd.setTitle("Jurassic Park");
}
}
The main method merely illustrates how a handler could use the DTO.
As long as you can extend one class into another, everything is fine. But, of
course, you can imagine a DVD DTO with any combination of properties from the DVD
bean, and you'd never make a DTO for every combination. What often is useful is
to create:
- A DTO with only a key.
- A DTO with the key and an important property, like the title of the DVD (often
used in GUI drop downs).
- A DTO with all the properties from the DVD
You can use the above scheme to make these classes.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
| 
