Wzór i relacje dao

Question

Pracuję z wzorcem DAO w PHP. Rozumiem, jakie korzyści daje oddzielenie modelu w ten sposób, ale nie rozumiem, w jaki sposób należy budować DAO i VO, gdy tabele są powiązane za pomocą jednostki asocjacyjnej

Podam przykład:

W moim DB mam

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

tworzę uservo, PostVO z odpowiednimi ustawiające i pobierające a następnie UserDAO i post DAO odpowiada za zapytania SQL, które na końcu zwracają VO. Wykonywanie operacji CRUD na danych z tych tabel jest bardzo proste, ale kiedy zaczynasz myśleć o odnosząca tabele i odzyskiwanie danych, która jest w różnych tabelach jest, gdy zaczynasz myśleć, że za pomocą DAO nie jest takie proste więcej ...

Jak czy chciałbyś uporządkować swój wzór DAO, jeśli chciałbyś zwrócić wszystkie uwagi autora artykułu? Nie potrzebuję zapytania SQL, które podaję jako przykład prawdziwej sytuacji ...

Przeczytałem, że dobrym pomysłem byłoby skojarzenie DAO i Vo dla każdego stołu skojarzeniowego. Na co składa się VO? Tylko 2 klucze obce lub wszystkie atrybuty z obu tabel?

Jeśli logika ma DAO i VO dla jednostki asocjacyjnej, jakie są rozwiązania, jeśli zapytanie przechodzi "przez" więcej niż 3 tabele (przy użyciu 2 jednostek asocjacyjnych)?

Wątpię, że wzór DAO miałby obiekt o nazwie users_posts_comments_article :)))

Thanks

Answer 1

jak siebie samego, jakiego rodzaju dane chcesz dostać i napisać warstwę, która zapewnia, że. Nie myśl o tym, co nazwać klasami, które łączą więcej niż dwie tabele. Zastanawiasz się nad przekształceniem tabel w modele i możesz zmierzać w kierunku, który nie jest odpowiedni dla twojego projektu. Ponieważ nie wiem, jak duży jest twój projekt, nie mogę powiedzieć, czy to będzie w porządku, czy nie.

Oto czytamy, że z pewnością daje trochę do myślenia: http://weierophinney.net/matthew/archives/202-Model-Infrastructure.html

Cytat z tego artykułu (on odnoszące się model domeny):

Kiedy myślisz w tych kategoriach, to startowym podzielenie twojego systemu na dyskretnych kawałków, które musisz poddać manipulacjom, które musisz poddać , a także rozważ, w jaki sposób każdy kawałek odnosi się do innych. Ten typ ćwiczenia pomaga również zatrzymać myślenie o modelu w kategoriach tabel bazy danych; zamiast tego Twoja baza danych staje się kontenerem w , której dane są przechowywane od jednego użycia twojego modelu do następnego. Zamiast tego Twój model to obiekt, który może wykonywać różne rzeczy z przychodzącymi lub przechowywanymi danymi - lub nawet całkowicie autonomicznie.

Answer 2

Zachowaj to proste, s. DAO lub jakakolwiek filozofia lub cokolwiek może mieć sens tylko do pewnego ograniczenia.

IMHO, to strata czasu dla tak prostej rzeczy jak blog, jeśli chcesz abstrakcji, po prostu przejdź do prostego getitem ("klasa", warunki $) lub uzyskaj powiązania ($ pathandconditions, $ itemconditions).

Tego rodzaju rzeczy zdecydowanie pokrywa wszystkie potrzeby, jakie możesz mieć do podstawowego wykorzystania sql.

getUsersWhoHaveAFrigginLongMethodNameofDoom jest naprawdę zły pomysł, określając takie unabstracted nadmiernie kopiować/wklejać funkcje idzie bezpośrednio przed konserwacji itp