Modèle et relations dao

Question

Je travaille avec le modèle DAO en PHP. Je comprends les avantages que vous obtenez en séparant votre modèle de cette façon, mais ce que je ne comprends pas, c'est comment êtes-vous censé construire DAO et VOs lorsque vos tables sont reliées par l'entité associative

Je vais donner un exemple:

Dans mon DB je

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

Je crée UserVO, PostVO avec correspondant setters et getters puis UserDAO et Poster DAO en charge des SQL qui à la fin retournent les VOs. L'exécution d'opérations CRUD sur les données de ces tables est très simple, mais lorsque vous commencez à penser à relier des tables et à récupérer des données dans différentes tables, vous commencez à penser que DAO n'est plus aussi simple ...

Comment organisez-vous votre modèle DAO si vous voulez renvoyer tous les commentaires faits par l'auteur de l'article? Je n'ai pas besoin de requête SQL Je donne juste ceci comme exemple de situation réelle ...

J'ai lu que ce serait une bonne idée d'avoir DAO associatif et Vo pour chaque table associative. En quoi consisterait sa VO? Juste 2 clés étrangères ou de tous les attributs des deux tables?

Si la logique est DAO et VO pour l'entité associative quelles sont les solutions si la requête passe "à travers" plus de 3 tables (en utilisant 2 entités associatives)?

Je doute que modèle de DAO aurait appelé objet users_posts_comments_article :)))

Merci

Answer 1

Comme vous quel genre de données que vous voulez obtenir et écrire une couche qui prévoit que. Ne pensez pas à ce qu'il faut appeler les classes qui rejoignent plus de deux tables. Vous envisagez de transformer vos tables en modèles et vous vous dirigez peut-être dans une direction qui ne convient pas à votre projet. Comme je ne connais pas la taille de votre projet, je ne peux pas dire si ce serait OK ou non.

Voici une lecture qui vous donnera certainement quelques éléments de réflexion: http://weierophinney.net/matthew/archives/202-Model-Infrastructure.html

Citation de cet article (il fait référence aux modèles de domaine):

Quand vous pensez en ces termes, vous début briser votre système en pièces discrètes dont vous avez besoin de manipuler, ainsi que de considérer comment chaque pièce se rapporte aux autres. Ce type d'exercice vous aide également à arrêter en pensant à votre modèle en termes de tables de base de données ; Au lieu de cela, votre base de données devient le conteneur dans dont les données sont persistantes d'une utilisation de votre modèle au suivant. Votre modèle à la place est un objet qui peut faire choses avec soit entrantes ou stockées données - ou même complètement de manière autonome.

Answer 2

Keep it simple, s. ou quelle que soit la philosophie DAO ou quoi que ce soit ne peut donner un sens à une certaine limite.

IMHO, c'est une perte de temps pour une chose aussi simple qu'un blog, si vous voulez l'abstraction, allez simplement getitem simple ('classe', $ conditions) ou être lié ($ pathandconditions, $ itemconditions).

Ce genre de choses couvre certainement tous les besoins que vous pouvez avoir pour sql de base.

Le getUsersWhoHaveAFrigginLongMethodNameofDoom est vraiment une mauvaise idée, la définition de ces unabstracted trop copier/fonctions collées contrecarre directement maintenabilité, etc.