Question

There is a third-party application, which database is accessed by my application. It’s database schema had been changed several times, so, there are about four different database schemas right now (different columns, different select conditions for the same entities).

For example, there is an entity “Application”. For different schemas it could be retrieved by:

1)SELECT * FROM apps WHERE cell_number < 65535 AND page_number < 65535 AND top_number = 65535

2)SELECT * FROM menu_item WHERE cell_number > -1 AND page_number > -1 AND parent_id = -1 AND component_name IS NOT NULL

And so on…

So, what design pattern (in Java) would be more comfortable to support multiple database schemas of different versions of the same application? It should be ready for future changes, of course.

Answer 1

It’s not an easy task because is difficult to proper map a table structure to an object (nowadays an ORM is often used to perform this task).

From your question seems that declaring Application as an abstract class or interface and provide different implementation is enough.

public abstract class Application(){
    public abstract Application getAnApplication();
}

public ConcreteApplicationOne(){
    public Application getAnApplication(){

      //retrieve application data from database scheama 1 , build object and return it.
    }
}

public ConcreteApplicationTwo(){
    public Application getAnApplication(){

      //retrieve application data from database scheama 2 , build object and return it.
    }
}

And using some sort of factory to build give to the user the right concrete Application class:

public class factory{
public Application getApplicationImplementation(){
if (cond1){
return new ConcreteApplicationOne();
}else {
return new ConcreteApplicationTwo();
}
}
}