I was recently involved in a discussion around a 'generic DAO API'. There's been a lot of Java EE goodness in recent years. Specifications such as JPA, EJB, CDI and JSF have made great strides to simplifying web application development. But anybody attempting to build a CRUD application in Java EE 6 will find there are
still significant pieces missing.
Like many others,
Kennard Consulting have had their own, proprietary 'generic DAO API' for many years. It's got all the usual features like CRUD, support for relationships, pagination and sorting, bookmarkable URLs, and so on. After 5 years of living with it, it's easy to be retrospective. There are certainly some things we'd do differently!
But I'll just highlight a few things that have worked out quite well. They're a bit unusual, but I think they're things any 'generic DAO API' should at least consider:
Custom EL ResolverA common (anti?) pattern I see is this:
@Named
public class PersonView
extends GenericView {
// Just for @Named
}
In most domains, there are
lots of entities. And if your
GenericView is any good, it should be able to supply most of the common operations for most of them. But then you still have to derive a skeleton class from the (abstract?)
GenericView just to expose it to JSF. This results in a huge number of boilerplate View classes (one per entity).
For our API, we instead wrote a custom EL resolver that knows how to map an EL name to a
GenericView automatically (in cases where one hasn't been explicitly @Named). This has saved us a significant amount of code.
To QBE or not to QBE?Query By Example (QBE) is a great way to develop search screens for CRUD applications. You can specify all the search fields as a Java Object, then write some generic code to translate that into JPA-QL. I would highly recommend a generic DAO API allow you to query using a partially populated version of an entity.
But
don't just limit it to the entity class itself! For example, if my entity is:
public class Person {
public String getName() { ... }
public Date getDateOfBirth() { ... }
}
Then sure it's great to be able to do:
Person search = new Person();
search.setName( "John Smith" );
Person found = queryByExample( search );
But it's also very useful to be able to create a specialized Search class:
public class PersonSearch {
public String getName() { ... }
public Date getBornAfter() { ... }
public Date getBornBefore() { ... }
}
So that I can do:
PersonSearch search = new PersonSearch();
search.setBornAfter( "1980-01-01" );
search.setBornBefore( "1990-01-01" );
Person found = queryByExample( search );
For this to work, you'll need to be able to annotate the PersonSearch class a little:
public class PersonSearch {
public String getName() { ... }
@Search( value = ComparisonType.GREATER_THAN, field = "dateOfBirth" )
public Date getBornAfter() { ... }
@Search( value = ComparisonType.LESS_THAN, field = "dateOfBirth" )
public Date getBornBefore() { ... }
}
But that in itself opens all kinds of interesting possibilities:
public class PersonSearch {
@Search( value = ComparisonType.CONTAINS )
public String getName() { ... }
@Search( value = ComparisonType.GREATER_THAN, field = "dateOfBirth" )
public Date getBornAfter() { ... }
@Search( value = ComparisonType.LESS_THAN, field = "dateOfBirth" )
public Date getBornBefore() { ... }
}
We've found such a capability very handy.
Sticky searchesHow you relate your entity to your view to your search object is open to a lot of personal preference. We have the view bean manage both the entity and the search object, but that's just us. However one thing our users have asked for is
the entity and the search object should have different lifecycles. In particular, the search should be session-based, so that every time the user comes back to the CRUD screen it's still there for them.
SecurityWhilst 'security through obscurity' is a bit frowned upon, it's a great safety net! Particuarly when you get down to the level of 'make sure user A can't see record B, even though user C should be able to see it'. It's easy to miss some of the rules. But a few things have really helped:
- Unguessable IDs: we use UUIDs for all our identifiers. For practical purposes these are unguessable - avoiding the situation where, say, a user who loads a customer record with an ID of 123 might try to load one with an ID of 124. To minimize the performance impact we store each UUID as a 128-bit integer, not as a String.
- Obscured IDs: we encrypt every ID (whether on the URL, or inside the HTML) relative to the logged-in user, preventing a scenario where one user can snoop an ID and try it under their own login.
- Temporary names: we use randomly generated names for all our HTML fields (at least in production). Furthermore these change with every page display/POST back.
In conclusion, these are just a few things that have worked out well for us over the past 5 years. They may not apply to your particular 'generic DAO API', but we think they're worth considering. Feedback welcome!
Version 2.0 of Metawidget is now available! We bumped the version number to reflect the fact we've broken binary compatibilty: this release no longer supports JDK 1.4. It also represents a significant maturing of the static form generation code:
I've had my ReadyNAS Duo nearly four years now, and have experimented with all sorts of things and reached some conclusions:
In