Attributes, attributes, and attributes

A lot of thanks for the people that sent me some persistence files.  It was a bit humbling for me that I only got less than 10 replies, but those good people are highly appreciated! If you feel guilty now, then don't hesitate to still sent me some files to my personal email!

Conclusion? Well, there is quite a variety out there and there is still a lot of diversity, lots of experimentation, and lots of struggling going on. Let me reflect on the most striking issue I noticed: Meta Data.

Persistence means your data is going to make a trip in a time capsule. Java was designed as an in-memory in-process programming language and this has as consequence that you need to provide some extra information how that trip should be made. What classes are persisted, where they are persisted, with what data types, under what name, etc. The most common approach is to use the javax.persistence annotations to markup a persistence object.

For smaller projects this seems to work well but I noticed that the larger projects went outside Java and escaped to text files. I have seen hibernate XML mapping files, proprietary XML files, and one project uses a Domain Specific Language (DSL) they developed with the Eclipse Enterprise Modeling Framework (EMF).

The advantages of annotations should be clear:

1. Minimizes redundancy since they interact with the Java type information
2. Can be safely refactored in all IDEs
3. Can use small names because of Java's package scoping
4. Type safe

However, one of the projects that used XML did not restrict itself to the persistence problem alone. The attributes of the persistent entities are not only used in Java to persist, they are also reflected as forms in the user interfaces and must be validated before they are stored.This meta-data is used in the GUI (potentially in another language), the core code, and the database (SQL Schema).  For each attribute, there are quite a large number of attributes on those domain attributes that must be defined by the developer. Using a proprietary file format or a DSL obviously provides for ample space to capture this information. Generators can then be used create the annotated data objects, SQL Data Definition Language files (DDL), HTML forms, Javascript validation, etc. This, of course, has the big disadvantage of requiring an extra step in the build. 

I must admit that  I find this model quite attractive considering that most enterprise applications must manage a very large number of attributes in a large number of entities and having a single definition of the domain model sounds awfully attractive; it can prevent a lot of redundancy. The surprise is of course that there is no dominant syntax for this information. The existing data description languages (ASN.1 or XML Schema anyone?) look utterly unusable for this purpose; these languages allow such complex data to be specified that generating Java, Javascript, HTML, etc. will be awfully complicated.

So what do you think? Just annotations on the Java Entity objects (potentially with extra validation annotations that can be used by the HTML5 GUI) or have a special domain object  specification file?

Peter Kriens @pkriens