[OOD] n-m kardinaliteit

[Verwijderd]

Stel ik heb een database ontwerp als volgt:

code:

tblUsers : user_ID | user_Name
tblUserGroups : usergroup_ID | usergroup_UserID | usergroup_GroupID
tblGroups : group_ID | group_Name

Hierbij is tblUserGroups een 'hulpmiddel' om een n-m relatie tussen gebruikers en groepen te realiseren.

De vraag is nu; hoe kan ik dit het beste 'vertalen' naar goede objecten? Met een tussenliggend 'UserGroup' object:

C#:

User.Groups = UserGroupBLL.GetByUser(this);

of is het beter als de UserDAL en GroupDAL dit direct doen:

C#:

User.Groups = GroupDAL.GetByUser(this);

Bij de laatste optie worden in de GroupDAL en UserDAL dan SQL Joins gebruikt. Ik ben zelf geneigd een tussenobject aan te maken, maar ik ben behoorlijk nieuw in de hele OOP scene, dus graag uw voorstellen.

[ Voor 14% gewijzigd door Verwijderd op 16-10-2005 13:45 ]

[Not Pingu]

Je kunt in je User object toch gewoon een collectie van Groups opnemen?
Je hebt dus een Group object nodig en een User object.

[Verwijderd]

Ik zou niet kiezen voor een tussenobject. In je database-model is het logisch dat je een n-m relatie zo realiseerd, maar bij het maken van je object-model heeft dit tussenobject een overbodige functie.

[Verwijderd]

Verwijderd schreef op zondag 16 oktober 2005 @ 14:19:
Ik zou niet kiezen voor een tussenobject. In je database-model is het logisch dat je een n-m relatie zo realiseerd, maar bij het maken van je object-model heeft dit tussenobject een overbodige functie.

Maar lever je dan niet een dimensie in; stel nou dat die n-m relatie ook nog een tijdsattribuut met zich meedraagt:

code:

tblUserGroups : usergroup_ID | usergroup_UserID | usergroup_GroupID | usergroup_AssignedDate

Als je nu een tussenobject (een soort 'library' zeg maar) hebt, is dit makkelijker mee te nemen, dan wanneer je de directe aanpak zou hanteren.

[Verwijderd]

Ik sluit mij aan bij skill4. De enige reden dat er in de database een tabel meer is dan real-world logica veronderstelt is dat databasetabellen geen n-m relaties kunnen hebben en je dus een tussentabel nodig hebt. Dat heb je in de OO wereld niet en dan is het logischer om gewoon te zeggen : "een user is lid van 0 of meer groepen" en "een groep heeft 0 of meer leden" wat dus veronderstelt dat een user object kan uitzoeken van welke groepen hij lid is en een groep welke leden hij heeft. Het is immers niet verplicht dat een DAL object naar slechts 1 tabel in de database mapped. Wil je dat per se wel dan zou ik er een DAL object bij maken voor memberships :

code:

User.Groups = MembershipDAL.GetByUser(User)
Group.Members = MembershipDAL.GetByGroup(Group)

Overigens : kunnen groepen zelf niet lid zijn van groepen?

[Verwijderd]

Verwijderd schreef op zondag 16 oktober 2005 @ 14:39:
Het is immers niet verplicht dat een DAL object naar slechts 1 tabel in de database mapped.
Wil je dat per se wel dan zou ik er een DAL object bij maken voor memberships :

code:

User.Groups = MembershipDAL.GetByUser(User)
Group.Members = MembershipDAL.GetByGroup(Group)

Duidelijk!

Overigens : kunnen groepen zelf niet lid zijn van groepen?

In dit voorbeeldje was ik daar niet van uitgegaan. Was ook meer om m'n vraag te illustreren.

[ Voor 3% gewijzigd door Verwijderd op 16-10-2005 14:43 ]