6/30/04
<< 72 Squared WeblogData Access Models - thick or thin?
the whole goal of constructing data access models is finding a way to communicate with the database that is easy to maintain, speeds up development time, and creates portable solutions. Otherwise, php programmers would just type the sql statement right into a variable in the script, and pass it directly to the database abstraction layer.
Personally, I don't think this is a bad approach. It is lightweight and directly applies to the task at hand. Many programmers opt for using data access objects, thinking it will allow them to re-use queries. The fact is, most queries are customized specifically to the task, and therefore are not re-usable.
The main advantage I find in using data access objects is portability. You can test and debug a data access object completely independent of the script you intend to use it for. The dao is not dependent on all of the variables in the script to align in their magical pattern to be certain it is working properly. Instead, the dao allows the programmer to build and test the query exactly as it will be performed in the script, but without the distraction of a thousand other variables getting in the way. This doesn't much matter on a small script, but in a large application testing becomes one of the most time-consuming aspects of the project.
Since my whole goal of building a data access object is to break the application down into small, easy-to-test components, I usually choose lightweight portability over trying to build a class that manages all of the different types of queries one might try to write to a specific table. In a way, my strategy is task-oriented, not object oriented.
Dao's were originally invented to try build an object oriented front-end to the table structure of a database. I found it easier to use them to encapsulate the logic of a specific database interaction.