dao pattern and relations

Question

I'm working with DAO pattern in PHP. I understand the benefits that you get from separating your model this way, but what I don't understand is how are you supposed to build DAOs and VOs when your tables are related through associative entity

I'll give an example:

In my DB I have

USERS(id,username);

USERS_POSTS(id_user(FK),id_post(FK));

POSTS(id, title);

USER_COMMENTS(id_user(Fk),id_post(FK));

COMMENTS(id, text);

I create UserVO, PostVO with corresponding setters and getters and then UserDAO and PostDAO in charge of SQLs that in the end return VOs . Performing CRUD operations on data from these tables is really simple, but when you start thinking about relating tables and retrieving data that's across different tables is when you start thinking that using DAO is not that simple any more...

How would you organize your DAO pattern if you wanted to return all the comments made by the author of article? I don't need SQL query I'm just giving this as an example of real situation...

I read that it would be a good idea to have associative DAO and Vo for every associative table. What would its VO consist of? Just 2 foreign keys or from all attributes from both tables?

If the logic is having DAO and VO for associative entity what's the solutions if the query goes "through" more than 3 tables (using 2 associative entities)?

I doubt that DAO pattern would have object called users_posts_comments_article :)))

Thanks

Answer 1

As yourself what kind of data you want to get and write a layer that provides that. Don't think about what to call classes that join more than two tables. You are thinking about turning your tables into models and you might be heading in a direction that is not appropriate for your project. Since I don't know how big your project is, I can't say whether this would be OK or not.

Here's a read that will definitely give you some food for thought: http://weierophinney.net/matthew/archives/202-Model-Infrastructure.html

Quote from that article (he's referring to Domain Models):

When you think in these terms, you start breaking your system into discrete pieces that you need to manipulate, as well as consider how each piece relates to the others. This type of exercise also helps you stop thinking of your model in terms of database tables; instead, your database becomes the container in which data is persisted from one use of your model to the next. Your model instead is an object that can do things with either incoming or stored data -- or even completely autonomously.