patrón y relaciones dao

Question

Estoy trabajando con el patrón DAO en PHP. Entiendo los beneficios que obtiene al separar su modelo de esta manera, pero lo que no entiendo es cómo se supone que debe crear DAO y VO cuando sus tablas están relacionadas a través de la entidad asociativa

Voy a dar un ejemplo:

En mi DB tengo

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 setters y getters correspondiente y luego UserDAO y Mensaje DAO a cargo de los SQL que al final devuelven los VO. Realización de las operaciones CRUD en los datos en estas tablas es muy simple, pero cuando empiezas a pensar en relacionar tablas y recuperación de datos que es a través de diferentes tablas es cuando se empieza a pensar que el uso de DAO no es tan simple como tampoco ...

Cómo ¿Organizarías tu patrón DAO si quisieras devolver todos los comentarios hechos por el autor del artículo? No necesito una consulta SQL. Solo estoy dando esto como un ejemplo de situación real ...

He leído que sería una buena idea tener DAO asociativo y Vo para cada tabla asociativa. ¿En qué consistiría su VO? ¿Solo 2 claves externas o de todos los atributos de ambas tablas?

Si la lógica tiene DAO y VO para entidad asociativa, ¿cuáles son las soluciones si la consulta pasa "más de 3 tablas" (usando 2 entidades asociativas)?

dudo que el patrón DAO tendría objeto llamado users_posts_comments_article :)))

Gracias

Answer 1

como a ti mismo qué tipo de datos que desea obtener y escribir una capa que proporciona eso. No piense en qué llamar a las clases que se unen a más de dos tablas. Está pensando en convertir sus tablas en modelos y puede estar yendo en una dirección que no es apropiada para su proyecto. Como no sé cuán grande es su proyecto, no puedo decir si esto estaría bien o no.

Aquí hay una lectura que sin duda le dará un poco de alimento para el pensamiento: http://weierophinney.net/matthew/archives/202-Model-Infrastructure.html

Presupuesto de ese artículo (se está refiriendo a los Modelos de Dominio):

Cuando se piensa en estos términos, se inicio rompiendo su sistema en piezas discretas que necesita manipular, así como también considerar cómo cada pieza se relaciona con las demás. Este tipo de ejercicio también le ayuda a detener pensando en su modelo en términos de tablas de base de datos ; en su lugar, su base de datos se convierte en el contenedor en cuyos datos persisten de un uso de su modelo al siguiente. Su modelo en su lugar es un objeto que puede hacer cosas ya sea con datos entrantes o almacenados de forma autónoma.

Answer 2

Keep it simple, s. DAO o cualquier filosofía o cualquier cosa solo puede tener sentido hasta cierto límite.

en mi humilde opinión, esto es una pérdida de tiempo para una cosa tan simple como un blog, si quieres abstracción, ir a por GetItem sencilla ('clase', $ condiciones) o ser relacionados (pathandconditions $, $ itemconditions).

Ese tipo de cosas definitivamente cubre todas las necesidades que puede tener para el uso básico de sql.

El getUsersWhoHaveAFrigginLongMethodNameofDoom es realmente una mala idea, definiendo dicha unabstracted excesivamente copiar/funciones pegados va directamente contra la facilidad de mantenimiento, etc.