dao pattern e relazioni

Question

Sto lavorando con pattern DAO in PHP. Capisco i benefici che si ottengono separando il proprio modello in questo modo, ma quello che non capisco è come si dovrebbero costruire DAO e VO quando le tabelle sono collegate attraverso l'entità associativa

Farò un esempio:

Nel mio DB ho

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); 

creo UserVO, PostVO con setter e getter corrispondenti e quindi UserDAO e Messaggio DAO responsabile di SQL che alla fine restituiscono VO. L'esecuzione delle operazioni CRUD sui dati di queste tabelle è davvero semplice, ma quando inizi a pensare di mettere in relazione tabelle e recuperare i dati attraverso tabelle diverse, inizi a pensare che usare DAO non sia più così semplice ...

Come organizzeresti il ​​tuo pattern DAO se volessi restituire tutti i commenti dell'autore dell'articolo? Non ho bisogno di query SQL Sto solo dando questo esempio di situazione reale ...

Ho letto che sarebbe una buona idea avere DAO associativi e Vo per ogni tabella associativa. In cosa consisterebbe il suo VO? Solo 2 chiavi esterne o tutti gli attributi di entrambe le tabelle?

Se la logica sta avendo DAO e VO per entità associativa, quali sono le soluzioni se la query passa "attraverso" più di 3 tabelle (utilizzando 2 entità associative)?

dubito che modello DAO avrebbe oggetto chiamato users_posts_comments_article :)))

Grazie

Answer 1

Come che tipo di dati che si desidera ottenere e scrivere un layer che prevede che. Non pensare a cosa chiamare le classi che si aggiungono a più di due tabelle. Stai pensando di trasformare i tuoi tavoli in modelli e potresti dirigerti verso una direzione che non è appropriata per il tuo progetto. Dato che non so quanto è grande il tuo progetto, non posso dire se questo sarebbe OK o no.

Ecco una lettura che sicuramente vi darà alcuni spunti di riflessione: http://weierophinney.net/matthew/archives/202-Model-Infrastructure.html

Citazione da tale articolo (si riferisce a modelli di dominio):

Quando si pensa in questi termini, è inizio rompere il tuo sistema in pezzi discreti che devi manipolare, come pure considerare come ogni pezzo si riferisce agli altri. Questo tipo di esercizio aiuta anche a fermare pensando al modello in termini di tabelle di database ; invece, il tuo database diventa il contenitore in i cui dati vengono mantenuti da un solo utilizzo del tuo modello al successivo. Il tuo modello invece è un oggetto che può fare cose con dati in entrata o memorizzati - o anche completamente autonomamente.

Answer 2

Resta semplice, s. DAO o qualsiasi altra filosofia o qualcosa può avere senso solo a un certo limite.

IMHO, questo è uno spreco di tempo per una cosa così semplice come un blog, se vuoi l'astrazione, basta andare per semplici getitem ('classe', $ condizioni) o ottenere correlati ($ pathandconditions, $ itemconditions).

Questo tipo di roba copre sicuramente tutte le esigenze che è possibile avere per l'utilizzo di base SQL.

Il getUsersWhoHaveAFrigginLongMethodNameofDoom è davvero una cattiva idea, definendo tale unabstracted eccessivamente copia/funzioni incollate va direttamente contro la manutenibilità, ecc