Is a DAO accessible only for accessing databases?

Question

I combed my design patterns and came across the thought that I could not find a good answer anywhere. Therefore, maybe someone with more experience can help me.

Is the DAO pattern designed to only access data in a database?

Most of the answers I found imply yes; in fact, most who speak or write according to the DAO pattern usually assume that you are working with some kind of database.

I do not agree. I could use DAO as 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 of which works with an SQL database, and one that works, say, in a graph data structure in memory. It's right? Or is it a graph implementation designed to be created in some other layer?

And if that's right, what is the best way to ignore the specific concrete details that each DAO implementation requires?

For example, take the class I criterion above. Suppose this is so:

 public final class Criteria { private String countryName; public String getCountryName() { return this.countryName; } public void setCountryName(String countryName) { this.countryName = countryName; } } 

For SQLCountryData, you must somehow map the countryName property to the SQL identifier so that it can generate the correct SQL. For the GraphCountryData, some Predicate Object can be created against the countryName property to filter the vertices from the graph, which does not work.

What is the best way to abstract away such details without associating client code that works with abstract CountryData with specific concrete implementation data?

Any thoughts?

EDIT:

The example that I included in the criteria class is simple enough, but think about whether I want to allow the client to build complex criteria, where they should not only specify the property to filter, but also the equality operator, logical operators for composite criteria and value.

Answer 1

DAOs are part of the DAL (data access layer), and you can have data supported by any implementation (XML, RDBMS, etc.). You just need to make sure that the project instance has been injected / used at runtime. DI frameworks like Spring / Guice shine in this case. In addition, your Criteria interface / implementation must be general enough to capture only business data (e.g. country criteria), and the actual mapping is again handled by the implementation class.

For SQL, in your case, you can generate an SQL query, generate it using a helper library like Spring, or use a full framework like MyBatis. In our Spring project, XML configuration files were used to decouple the client and implementation; this may change in your case.

EDIT: I see that you raised a similar problem in the previous question. The answer still remains unchanged. You can add as much flexibility as you want in your interface; you just need to make sure that the implementation is smart enough to understand all the arguments it receives and matches them accordingly with the original source. In our case, we extracted the value object from the business layer and converted it into a map at the SQL implementation level, which MyBatis can use. Again, this process was fairly transparent, and the only way for the service level to interact with the DAO was through objects with a specific interface.

Answer 2

No, I do not believe that this is only related to databases. Abbreviation for Data Access Object , not "Database Data Access Object ", so it can be used with any type of data source.

The thing is to separate the application from the data warehouse of the backup storage so that the storage can be modified as desired, provided that it still follows the same rules.

This does not just mean Oracle and implementation in DB2. It can also mean switching to a completely non-DBMS based solution.

Answer 3

OK, this is a little philosophical question, so I’ll tell you what I’m thinking about. DAO usually refers to a data access object. Here the data source is not always a database, although in the real world implementations usually resort to this. It can be XML, a text file, some remote system, or, as you indicated in the graph of objects in memory.

From what I saw in a real project, yes, you're right, you should provide different DAO implementations for accessing data in different ways. In this case, one dao goes to DB, and the other dao implementation goes to the object graph.

The DAO interface must be designed very carefully. Your “criteria” should be generalized enough to encapsulate how you intend to receive data. How to achieve this level of isolation? The answer may vary depending on your system, in general, I would say the answer will be "as usual, adding another level of indirection" :)

You can also think of your criteria object as a data object, where you specify only the data needed for the query. In this case, you don’t even need to support different criteria. Each specific DAO implementation will take this data and process it in its own way: one will build a query for the graph, the other will attach it to your SQL.

To minimize maintenance issues, I suggest you use dependency management structures (like Spring). Typically, these frameworks are well suited for creating DAO objects and collaboration. Good luck

Answer 4

No, DAO for databases is a common misconception.

DAO is a "data access object", not a "database access object". Therefore, wherever you need CRUD data to / from (e.g. file, memory, database, etc.), you can use DAO.

Domain Driven Design has a repository template. Although Repository as a word is much better than three random letters (DAO), the concept is the same.

The purpose of the DAO / Repository template is to abstract the backup data store, which can be anything that can contain state.