Where to put business logic for two related objects?

Question

Suppose I have two entities: User and UserGroup.
They have a one-to-many relationship => each UserGroup virtually contains 0 to n number of users.

If I want to retrieve the users for a UserGroup where in my business layer would be a better class to put that method?

1. In UserManager, add method: GetAllUsersForUserGroup
2. in UserGroupManager add the above method.

Guess 2 is better. But I'm not sure.
Thanks.

UPDATE
Guess I couldn't completely explain what I meant.
Yes we can have User, Users, Group, Groups, etc.

But I'm not trying to find out what different patterns, etc can be applied to implement the business. my question is: do you put GetAllUsersForUserGroup(int UserGroupID) in UserManager or in GroupManager? Do you think GetAllUsersForUserGroup(int UserGroupID) should be defined in a class that is managing users or in a class that's managing user groups?

Answer 1

Of course it's difficult to give an opinion without knowing exactly how the managers and the clients of the managers are structured and what methods they already offer.

Assuming the managers are simple DAOs with CRUD operations for the basic entity operations I'd think about having a higher level UserRepository or UserService object providing more 'business' like functions such as an

IList<User> FindUsersByGroup( UserGroup group );

In summary though, there's no right answer as logically you could argue either way - I'd base my decision on keeping the managers as simple as possible, avoid object bloat, keep an eye on how you see the application evolving in the near future and refactor if necessary it maintainability becomes an issue.