Mod4j: Modeling for Java using Domain Specific Languages

Ok, got it checked in on a branch, all unittests running again. But. There are a few reasons I don't merge it just yet:

Now about the optimistic locking: do we want to do it in the service layer?

Pro

• Checking at the gate (fail early)
• We don't have to create a setter for the version domain object field

Contra

• Is it our concern? (Hibernate can do it for us).
• We need a setter for the version domain object field (Does Hibernate like that? Do we need to detach the domain object first? A proof of concept is needed..)

And now consider this: version has a 'status aparte' (like ID): it's not included as property in the model. If we're going for the 'contra' (ie letting Hibernate handle it) that is no longer true: for the Datacontract DSL and beyond, it's just another property, no reason to treat it any differently. If it's "just another property" it wil be normally copied as any other property. Why not make it a normal property? Well, I know, this will open up a can of whoopass regarding the Hibernate configuration generation... or maybe leave it implicit in the BusinessDomain DSL but explicit in the CrossX interface to the Datacontract DSL? This is not a complete story, I haven't thought this through completely (I have to finish a thesis as well you know ).

The DtoTranslator is getting a thorn in my eye. First, I don't like the name. Not really much is translated: only the enumerations are really translated really (and is that necessary by the way? Why do we need a DTO-version of the enum? Haven't thought this through, I might be missing something). For the rest, it is a Mapper (Data Mapper pattern, Fowler) or a Adapter (GoF design pattern). Because it is not 100% clear what the responsibilties of a 'translator' are, the class is no longer cohesive. It does a little mapping, a little translating, a little factory-ing (creating new business objects), a little null-checking, a little ID checking, a little version checking.. it's getting messy. We don't want to redesign the whole ruddy thing right now, but we need to be aware of this.

So, back to not fixing 100 problems at once: what now? Go for the rudimentary optimistic locking in the Translator? Or...?

Letting Hibernate check the version won't work. See: http://forum.springsource.org/showthread.php?t=23736

So for the moment we'll have to do it ourselves in the mappers (better name than translators) and throw an exception.

Still, we also will have to account for canonical datamodels that are outside of our control and do not have a version element. How do we perform optimistic locking then?

If you are going to do some proof-of-concept, have a look at http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#transactions-optimistic-customizing. It looks like you can have optimistic locking based on the old and new values of all properties, or the old and new values of just the changed properties, without having to carry around either a version or a timestamp property.

Regarding the link: I'm reading that it will work - as long as the domain object is evicted from the session. I can think of several ways to do this using the transaction manager (that opens/closes the Hbm session as well, right?), but also all kinds of nasty LazyInitialization exceptions that will occur populating the DTOs (since the session is closed) And the final post states it 'just works'. Well, one way or another, this solution needs a proof of concept.

As to your second question: I can think of several (ugly) solutions, but I'm sure we're not the first people asking ourselves this question. Don't wanna read up on that right now though

Merged from 'branches/MODFORJ-141'.