Hi all
I'm currently building a system using DAOs (accessing a relationship database) to generate domain objects.
The intention to to try and ensure as little dependency between the domain objects and DAOs, so that I could in the future replace the DAOs without having to rebuild the domain layer.
I'm currently confused about the best way to approach one concept.
I need to create a list of users within a group
EITHER I ask the Group DAO to create a list of user objects
-the Group DAO would get a list of user keys, and for each one ask the User DAO to create a new User Object which will all be added into a User List Object which I can then iterate through
OR I ask the User DAO to create a list of User Objects for a given group
- the User DAO would be fed a group key, and then create a new User Object for every case which would be added to the User List Object.
For me the first case makes more sense, but it means that the Group Dao now understands how Users are assigned to it, increasing the coupling within my system.
Any thoughts?
To extend this thought I'm thinking through the following options
Either I can ask the Group -> getUserList(self)
or I can ask the User -> getSelfList(group)
this then poses the question if I want to know which group(s) a user belongs to should I do....
Group->getSelfBy(user)
User->getGroupBy(self)
Thanks
Alec
OOP Design: Should groups create lists of users? or...
Moderator: General Moderators
-
alecsammon
- Forum Newbie
- Posts: 1
- Joined: Wed Jun 30, 2010 4:48 am
Re: OOP Design: Should groups create lists of users? or...
Personally I would set this up so that it makes the most sense in the context of the application.
If the group is being used for security purposes (ie group Admin has all user permissions while User can only view records) then that's really just an extension of the User which dictates the user's access permissions. However if the group is something like musical rock bands then yes, the group dictates the users. Members of the band can come and go but the "band" is still an entity in and of itself.
If the group is being used for security purposes (ie group Admin has all user permissions while User can only view records) then that's really just an extension of the User which dictates the user's access permissions. However if the group is something like musical rock bands then yes, the group dictates the users. Members of the band can come and go but the "band" is still an entity in and of itself.
Re: OOP Design: Should groups create lists of users? or...
It doesn't matter. Pick one or both. You can still have $group->getUsers() without the group object knowing about data access. Look up lazy loading
http://en.wikipedia.org/wiki/Lazy_loading
But you wouldn't ask a user to list other users (well most programmers would). Typically you would ask a "user mapper" to list out users. If you want to query right thru your domain model then the clear choice is to ask the group to list users.
Which goes back to what I said, if you do so its completely uncoupled, you would have "mappers" for each model. At that point you could ask the user mapper to list users for a given group.
So either of these would be "correct"
or
The latter leaves things as uncoupled as can be.
http://en.wikipedia.org/wiki/Lazy_loading
But you wouldn't ask a user to list other users (well most programmers would). Typically you would ask a "user mapper" to list out users. If you want to query right thru your domain model then the clear choice is to ask the group to list users.
Which goes back to what I said, if you do so its completely uncoupled, you would have "mappers" for each model. At that point you could ask the user mapper to list users for a given group.
So either of these would be "correct"
Code: Select all
$group->listUsers(); // array() Code: Select all
$userMapper = new UserMapper;
$userMapper->listUsersForGroup($group); // array