In de database zijn mijn tabellen gekoppelt dmv 1:n relaties of vaak n:m relaties, een voorbeeld:
users, roles en users-to-roles
users, images en users-to-images
Nu vraag ik me af, hoe moet ik dit in de objecten doen, hoe maak ik die relatie? Maak ik de koppel class (userToRoles bijv, of imagesToUser) puur afhankelijk van de andere twee classes? Want die twee moeten opzich zelf kunnen werken zonder afhankelijk te zijn van een ander.
Wat Jan zegt klopt, maar als je MVC gaat toepassen is dit inderdaad een reëel probleem waar je tegen aan loopt in je Model.
Als je deze relaties in models wil implementeren zijn er heel veel punten om over na te denken. Een van de belangrijkste punten is dat een database gewoon anders in elkaar zit dan een OO model. Niet iedere tabel hoeft een bij behorende klasse te hebben. Sterker nog een tabel kan wel meerdere klassen hebben die bij deze tabel horen.
Goed, jouw probleem met koppel tabellen. Ik denk dat dit afhangt van de koppel tabel, als deze alleen de primary key's van beide tabellen bevat, is er geen noodzaak tot het toevoegen van een klasse hier voor. Voorbeeld:
De primary key van users is use_id en de primary key van roles is rol_id.
De koppel tabel userrole bevat de kolommen use_id en rol_id
In dit geval kan ik me voorstellen dat je twee klassen hebt; User en Role
Ik zou de klasse user dan een eigenschap geven die een array met alle role objecten terug geeft en de klasse Role een eigenschap die een array met alle User objecten terug geeft.
Stel nu dat er een extra kolom uir_datumtoegekend in de koppel tabel had gezeten, dan zou het wel nodig zijn om een klasse voor deze tabel te maken.
Ik ben het niet met Boaz eens. Je kunt van te voren kiezen of je deze data abstraction in zijn geheel wèl of niet met objecten wil oplossen. In een goede OOP omgeving wil je dit wel. Als je kijkt wat veel gebruikt wordt in de OOP-wereld dan zie je bijvoorbeeld Java Beans, ActiveRecord en Data Access Service.
Die laatste is denk ik zeer geschikt. Google bijvoorbeeld eens op 'Zend SDO' en klik de eerste link, geschreven door IBM'ers. SDO (Service Data Objects) gaan net een stap verder dan puur data abstraction (zoals Zend_Db_Table) en data access (zoals PDO).
Er zijn 1000 keuzes te maken en het heeft alles te maken met applicatiearchitectuur en dat is een vak apart, maar ik zou zeker eens kijken naar Service Data Objects c.q. Data Access Service zoals in Java en PHP. Al is het om inzicht te krijgen in bepaalde methodes. Ook Zend_Db_Table zou ik eens bekijken om ideeën op te doen m.b.t. relaties.
Wat mijn verschil in mening met Boaz denk ik is is dat hij de Model ziet als Data Access/Abstraction, en ik de Model als meerdere separate lagen, waardoor het hele verhaal over koppeltabellen niet meer relevant is. De Model bevat al je business logic inclusief de data-laag die op zichzelf weer bestaat uit data access, data transfer en data abstraction. En ik ben voorstander die data-laag altijd in objecten te vormen voor flexibiliteit.
Ik heb het gevoel dat ik voor een iets eenvoudigere oplossing heb gekozen, maar helaas vind ik jou verhaal nogal onbegrijpelijk. Kan je duidelijk uitleggen wat nu het concrete verschil is tussen jou en mijn aanpak?
Nou, ik heb er over nagedacht en een oplossing gevonden (denk ik), ik houd gewoon de classes roles en users. De class users-to-roles of user-to-images zorgt in de db voor een relatie, en ook in de class is dit zo. Users en roles moeten apart kunnen werken, maar de relatie-class die er tussen zit is speciaal voor die relatie gemaakt (net als in de DB) het is dus niet erg als er binnen die class een hoop afhankelijkheid is.
Dit geld natuurlijk alleen voor n:m relaties, voor 1:n of n:1 zou dit anders zijn, daar ga ik nog even naar kijken.
