Witam!
Piszę sobie obiektową otoczkę dla bazy danych. Mam kilka wątpliwości. Jeżeli wyszykuję w jakiejś tabeli rekordu to sprawa jest prosta, zwraca mi obiekt klasy tej tabeli (np DAO_User). Co jednak jeśli złączę kilka tabel? Co wtedy powinienem dostać?
Pozdrawiam!

Powinieneś mieć jakiś z góry ustalony sposób zwracania danych z DAO.

1. Tablica.
2. Popularnym w wielu frameworkach jest tworzenie dodatkowej, generycznej, klasy Record (i RecordSet, czyli zbiór rekordów) uzbrojoną w zestaw metod potrzebnych do wyciągnięcia z niej danych - którą w miarę potrzeb możesz rozszerzać dla specyficznych przypadków.

Chcę mieć zwrócony obiekt dostępowy. Mogę zrobić uniwersalny obiekt, ale jak mam złączenie w zapytaniu to co jeśli wywołam metodę save(); Skąd wiem, które dane zapisać do której tabeli?

No to albo powinien to obsługiwać twój model danych na podstawie tego co łączy i jak; albo określić inny niż domyślny obiekt dostępu i przeładować metodę save() jeżeli podstawowe funkcje DAO nie są w stanie tego zautomatyzować.

Ale skąd bez analizy zapytania sql mam wiedzieć co zapisać, w której tabeli?

Metadanymi?

Zaszytymi modelach informacjami o relacjach etc...

Jeżeli w tabeli występuje klucz obcy to oczywiście będzie on zapisany w modelu danych. To nie jest problem. Problemem jest jeżeli w zapytaniu połącze tabele w niestandardowy (z punktu widzenia modelu danych) sposób.

Tzn... Możesz podać przykład?

I nie rozumiem stwierdzenia "w niestandardowy sposób" - w pojęciu modelu nie ma czegoś takiego. Jednakże, wydaje mi się, że jeżeli już takie "niestandardowe łączenie" występuje, powinieneś dopisać jego obsługę w konkretnym modelu - z samej nazwy można wywnioskować, że coś podobnego występuje sporadycznie.

Może inaczej. Łączę tablę użytkownik i grupa po id. Dostaję tablicę wyników. Jak ją przerobić na kolekcję obiektów. Jak mogę sprawdzić, które pole należy do której tabeli? Łopatologicznie proszę i najlepiej z przykładem. Mam dość spory bałagan w głowie w tej kwestii.
Dziękuję za wsześniejsze wskazówki i za cierpliwość.
Pozdrawiam!

Heeh, chyba trochę za późno na to - po za tym z prostego DAO wyszedłby z tego ORM

Pozdraiwam, LBO.

P.S. Pomyśl nad jakimś gotowym rozwiązaniem.

Piszę to w celach edukacjnych więc gotowe rozwiązania odpadają. Patrzę jak to wygląda w Propelu właśnie. Link: http://propel.phpdb.org/trac/wiki/Users/Do...3/Relationships

Standaryzacja! Tymże jeżeli standaryzujemy to jak najmniej, najwygodniej. Choć sam nie stosuje DAO w swoich projektach to wykonanie było by banalne ponieważ mapuje tabelę i prefiksy ich kolumn tak by były unikalne. Dla przykładu dla tabeli users kolumny to: u_id, u_name. Tabela news ma natomiast: n_id, n_name.

Prefiksy muszą być unikalne i wiadomo do której tabeli należy dana.

Dzięki! Propozycja jest dobra, ja jednak lubię uniwersalne rozwiązania. Popatrzyłem trochę jak to wygląda w Propelu i zrobię coś na podobnej zasadzie. Na początek zapiszę dane na sztywno w klasach tabel. Dziękuję wszystkim za wskazówki. Jeżeli ktoś ma jeszcze jakieś sugestie to będę zobowiązany!
Pozdrawiam!

Odniosę się do Twojego przykładu user i group.

Klasy jak będą Ci potrzebne to UserDAO, GroupDAO, UserVO, GroupVO (bliżej o tym tutaj).

Do tego należało by wykorzystać dobry pomysł MMPrime z mapowaniem nazw kolumn. Tylko pytanie czy robić to poprzez klasy DAO czy od razu już nadać odpowiednie nazwy kolumnom w poszczególnych tabelach.

I teraz w zależności w jakim kontekście będziesz używać złączenia Users i Groups musisz wybrać w której z klas DAO zaimplementować metodę złączającą usera z groupą.
Po złączeniu otrzymasz result z DB który przekażesz do konstruktorów poszczególnych obiektów UserVO i GroupVO, a konstruktor już sobie wyłuska interesujące go pola.
Następnie zrobisz co tam chcesz zrobić na tych danych i biorąc pod uwagę relacje między nimi (klucze obce) zwrócisz te obiekty VO do odpowiadających im klas DAO by wykonać metodę DAO->save().