Think for a while that nowadays we have popular ORM’s (like the Entity Framework), popular managed query languages (like Linq) and data base services (like DynamoDb) that abstract you from many of the underlying data access design patterns.
The general answer is no, they are not relevant nowadays because many of those are outdated and solved problems that don’t exist anymore (see their strengths and weakness). A more specific answers is: depends on how you are going to use them.
If you are doing “rapid applications” go ahead and use the Active Record -AR- design pattern, by the way, you could also use Visual Basic 6 and be part of the silent majority. If you are not “rapid” but instead “agile” use the Entity Framework (and thus design patterns like DAO, Data Mapper and QueryObject). By other hand, if you are designing API for accessing storage media (imagine you are inventing USB based data storage) move forward with the TDG/RDG.
The problem with all of these patterns is not that they don’t work; in fact they do work in the scenarios for they were designed for. The problem is that those scenarios are not relevant and a new level of abstraction is between the low level ones (TDG, RDG and AR) and the high level DAO. This level of abstraction does not care about the underlying infrastructure (remember we have now data base services like DynamoDb) and fits into a broader a type of highly usable applications.
Nowadays we (as the loud majority) build enterprise applications where is not enough having only one class dealing with all the operations on a table, for sure you can put all together but your code will be hard to understand and to maintain. Nowadays we have tables that are consumed in different formats (imagine an Orders table, you do need more than one class for exposing its operations –views, filters, sorting-) and work with other classes (a table like Orders heavy depends on tables like OrderDetails).
The only one pattern of those that we can reuse and improve for today’s applications it’s the DAO, I say reuse because the notion of abstracting of the underlying data storage is still relevant, must be improved because our tables have gone far away of having a 1:1 relation between tables and objects. So you’re better of thinking in your data layer as services, likewise group your packages into sets of related services, no matters if a service is made of multiple data storage or database services.
For example: you will have a package for performing searches on different domain concepts; imagine an OrderFinder or an OrderGrouping class; these classes are designed to provide a set on services, so think about your data layer and data packages as Data Service Objects.
I guess the concept of Data Service Objects will help you to better separate your functionality and avoid ending up with classes with more than 7 methods. If you have more than 7 methods in your current DAO classes is because the standalone fact of operating in the same table is not enough for designing/separating purposes.
Javier Andrés Cáceres AlvisMicrosoft Most Valuable Professional – MVP Intel Black Belt Software Developer