DAO within relational schemes

[oddz]

Oddz do you still use a DAO per table or you have a generic DAO?

No – I have been using a ActiveRecord based system.

$user = new User(
    array(
        'username'=>'isausername'
        ,'password'=>'isapassword'
        ,'email'=>'sa@email.com'
        ,'profile'=>new Profile(
            array(
                'firstname'=>'isafirstname'
                ,'lastname'=>'isalastname'
                ,'page'=>'isaage'
            )
        )
    )
);
$user->save(); 

$user = User::find(
    'one'
    ,array(
        'include'=>'profile'
        ,'username'=>'isausername'
    )
);
$user['profile']['lastname']; 

You can catch a glimpse of the evolving library here if you like.

It all works on a generic level once the tables have been defined in terms of relationships, fields, etc.

[oikram]

I will stay with DAO I guess, at least for now. At least for this project. At least for sometime. Otherwise, I will end up on developing absolutely nothing. However, I find myself in a position where I need to deal either with one general DAO or one DAO per table, where the last one, on my opinion, is pretty much organized and simple for my newbility. But if your experience on several DAOs have been catastrophic or something, I'd like to hear before I walk on the same road.

Regards,
Márcio

[oddz]

Well if something has been working for you I wouldn't recommend changing it.

I developed my own to eliminate code repetition and database changes in a agile development environment. Also, to support calculated columns, aggregates, subqueries and elimination of repeating results when two or more tables are joined together in anything other than a 1:1 relationship.

Just for example I recently added a field to one of my apps tables. It then took only one line of code in my model for that table for the entire application to support it. However, if the queries where hard coded in a DAO structure I would need to go through each DAO and write in that column – no thanks.

The other thing that I always find teeth pulling is support for aggregates and calculated columns. Something that was written into the library from the very beginning were most libraries would require some form of lazy loading or self defined methods to achieve the same thing. For instance finding all users and their number of blogs. Easily supported with the following syntax that issues one query.

$users = User::find(
    array(
        'dynamic'=>array(
            'num_blogs'=>'count(*)'
        )
        ,'include'=>'blogs'
        ,'group'=>'id'
    )
    ,array(
        'require'=>false
    )
);
echo $users[2]['num_blogs']; 

However, those are/were my specific needs and wants for managing database info on the domain side of things. If the DAO is working well for you then you shouldn't change it. Especially if you have developed a large portion of the app using that methodology.