Question

So here’s my conundrum. I am programming a tool that needs to work on old versions of our application. I have the code to the application, but can not alter any of the classes. To pull information out of our database, I have a DTO of sorts that is populated by Hibernate. It consumes a data object for version 1.0 of our app, cleverly named DataObject. Below is the DTO class.

public class MyDTO {  
    private MyWrapperClass wrapper;  

    public MyDTO(DataObject data) {
        wrapper = new MyWrapperClass(data);
    }
}

The DTO is instantiated through a Hibernate query as follows:

select new com.foo.bar.MyDTO(t1.data) from mytable t1

Now, a little logic is needed on top of the data object, so I made a wrapper class for it. Note the DTO stores an instance of the wrapper class, not the original data object.

public class MyWrapperClass {

    private DataObject data;

    public MyWrapperClass(DataObject data) {
        this.data = data;
    }

    public String doSomethingImportant() { ... version-specific logic ... }
}

This works well until I need to work on version 2.0 of our application. Now DataObject in the two versions are very similar, but not the same. This resulted in different sub classes of MyWrapperClass, which implement their own version-specific doSomethingImportant(). Still doing okay. But how does myDTO instantiate the appropriate version-specific MyWrapperClass? Hibernate is in turn instantiating MyDTO, so it’s not like I can @Autowire a dependency in Spring.

I would love to reuse MyDTO (and my dozens of other DTOs) for both versions of the tool, without having to duplicate the class. Don’t repeat yourself, and all that. I’m sure there’s a very simple pattern I’m missing that would help this. Any suggestions?

Answer 1

My co-worker and I tried many options. We settled on using Hibernate’s poorly documented ResultTransformer interface (really, Hibernate, the lack of documentation there is shameful). Although use of the Transformer forced us to manually parse an Object[] array in our MyDTO constructor, it was a worthy tradeoff.

In the ResultTransformer, we injected a version-specific WrapperFactory through Spring. We changed our queries to allow ResultTransformer to instantiate MyDTO, and voila! Problem solved. Below are our modified query and DTO class:

"select t1.data from mytable t1"

---

public class MyDTO<T> {  
    private MyWrapperClass wrapper;  

    public MyDTO(Object[] fields, WrapperFactory<T> wrapperFactory) {
        T data = (T) fields[0];        
        wrapper = wrapperFactory.newWrapper(data);
    }
}

As per my comments to Guillaume, the Interceptor did not work as hoped. Presumably because MyDTO is not a persistent class.

We also tried having the DTO access the ApplicationContext directly through a singleton class, and from there obtaining the WrapperFactory. Although this worked, it predictably fubar’d our unit tests, and we scrapped the approach.