9

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

luigi7up
  • 5,779
  • 2
  • 48
  • 58
  • Great, I got three upvotes :p Now, could anyone tell us more about this problem :) I know there is ORM in rescue, but then I don't get the poing of DAO :))) – luigi7up Jun 24 '11 at 13:45
  • And I almost forgot... I have a feeling that if I start implementing things that deal with relationships I'll end up reinventing the wheel - namely ORM?! – luigi7up Jun 24 '11 at 14:10

2 Answers2

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.

Julian
  • 8,808
  • 8
  • 51
  • 90
  • Julian, thank you for your answer, but could you be a bit more specific in your answer? You say "and write a layer that provides that". What exactly would you finally have? – luigi7up Jun 27 '11 at 08:32
  • 2
    You could have something like this: `class BlogService` and in there have `getCommentsForUser($userId)`, `getUsersWhoNeverValidatedTheirEmailAddress($options)`, etc, etc. This way you are seeing your Blog in a more generic way rather than being constrained to what your db table classes can do. – Julian Jun 27 '11 at 13:38
  • The extra service layer is a good idea. Leave the data layer do the basic stuff and the services can combine them to form more complex processes. – James P. Aug 31 '13 at 03:22
0

Keep it simple, s. DAO or whatever philosophy or anything can only make sense to a certain limit.

IMHO, this is a waste of time for such a simple thing as a blog, if you want abstraction, just go for simple getitem('class',$conditions) or get related ($pathandconditions,$itemconditions).

That kind of stuff definitely covers all the needs you can have for basic sql use.

The getUsersWhoHaveAFrigginLongMethodNameofDoom is really a bad idea, defining such unabstracted overly copy/pasted functions goes directly against maintainability etc.

Morg.
  • 697
  • 5
  • 7