Question

I have been brushing up on my design patterns and came across a thought that I could not find a good answer for anywhere. So maybe someone with more experience can help me out.

Is the DAO pattern only meant to be used to access data in a database?

Most the answers I found imply yes; in fact most that talk or write on the DAO pattern tend to automatically assume that you are working with some kind of database.

I disagree though. I could have a DAO like follows:

public interface CountryData {
    public List<Country> getByCriteria(Criteria criteria);
}

public final class SQLCountryData implements CountryData {
    public List<Country> getByCriteria(Criteria criteria) {
        // Get From SQL Database.
    }
}

public final class GraphCountryData implements CountryData {
    public List<Country> getByCriteria(Criteria criteria) {
        // Get From an Injected In-Memory Graph Data Structure.
    }
}

Here I have a DAO interface and 2 implementations, one that works with an SQL database and one that works with say an in-memory graph data structure. Is this correct? Or is the graph implementation meant to be created in some other kind of layer?

And if it is correct, what is the best way to abstract implementation specific details that are required by each DAO implementation?

For example, take the Criteria Class I reference above. Suppose it is like this:

public final class Criteria {
    private String countryName;

    public String getCountryName() {
        return this.countryName;
    }

    public void setCountryName(String countryName) {
        this.countryName = countryName;
    }
}

For the SQLCountryData, it needs to somehow map the countryName property to an SQL identifier so that it can generate the proper SQL. For the GraphCountryData, perhaps some sort of Predicate Object against the countryName property needs to be created to filter out vertices from the graph that fail.

What’s the best way to abstract details like this without coupling client code working against the abstract CountryData with implementation specific details like this?

Any thoughts?

EDIT:

The example I included of the Criteria Class is simple enough, but consider if I want to allow the client to construct complex criterias, where they should not only specify the property to filter on, but also the equality operator, logical operators for compound criterias, and the value.

Answer 1

DAO’s are part of the DAL (Data Access Layer) and you can have data backed by any kind of implementation (XML, RDBMS etc.). You just need to ensure that the project instance is injected/used at runtime. DI frameworks like Spring/Guice shine in this case. Also, your Criteria interface/implementation should be generic enough so that only business details are captured (i.e country name criteria) and the actual mapping is again handled by the implementation class.

For SQL, in your case, either you can hand generate SQL, generate it using a helper library like Spring or use a full fledged framework like MyBatis. In our project, Spring XML configuration files were used to decouple the client and the implementation; it might vary in your case.

EDIT: I see that you have raised a similar concern in the previous question. The answer still remains the same. You can add as much flexibility as you want in your interface; you just need to ensure that the implementation is smart enough to make sense of all the arguments it receives and maps them appropriately to the underlying source. In our case, we retrieved the value object from the business layer and converted it to a map in the SQL implementation layer which can be used by MyBatis. Again, this process was pretty much transparent and the only way for the service layer to communicate with DAO was via the interface defined value objects.