Где разместить бизнес-логику для двух связанных объектов?

Question

Предположим, у меня есть две сущности: User и UserGroup.
Они имеют отношение один ко многим => каждая UserGroup фактически содержит от 0 до n пользователей.

Если я хочу получить пользователей для UserGroup, где на моем бизнес-уровне лучше использовать этот метод?

1. В UserManager добавьте метод: GetAllUsersForUserGroup
2. в UserGroupManager добавьте вышеуказанный метод.

Угадайте, 2 лучше.Но я не уверен.
Спасибо.

ОБНОВЛЕНИЕ
Думаю, я не мог полностью объяснить, что я имел в виду.
Да, у нас может быть User,Users, Group, Groups и т. Д.

Но я не пытаюсь выяснить, какие различные шаблоны и т. Д. Можно применить для реализации бизнеса.мой вопрос: вы положили GetAllUsersForUserGroup(int UserGroupID) в UserManager или в GroupManager?Как вы думаете, GetAllUsersForUserGroup(int UserGroupID) должно быть определено в классе, который управляет пользователями, или в классе, который управляет группами пользователей?

Answer 1

Конечно, сложно дать заключение, не зная точно, как устроены менеджеры и клиенты менеджеров и какие методы они уже предлагают.

Предполагая, что менеджеры - это простые DAO с операциями CRUD для основныхОперации с сущностями Я бы подумал о наличии объекта UserRepository или UserService более высокого уровня, предоставляющего более «деловые» функции, такие как

IList<User> FindUsersByGroup( UserGroup group );

Таким образом, нет правильного ответа, как логическиВы могли бы поспорить в любом случае - я бы основывал свое решение на том, чтобы менеджеры были максимально простыми, избегал раздувания объектов, следил за тем, как вы видите развитие приложения в ближайшем будущем, и, если необходимо, проводил бы рефакторинг, чтобы его ремонтопригодность становилась проблемой.

Answer 2

Как сказал @Tom Carter, трудно найти точно лучший ответ для вас, потому что не хватает многих деталей. Я думаю, что большинство "менеджерских" классов можно удалить с помощью хорошего ООП.

Ваш класс UserGroup может выглядеть примерно так:

public class UserGroup
{
    private List<User> _Users;

    public ReadOnlyCollection Users
    {
        get { return _Users.AsReadOnly (); }
    }

    public void AddUser (User User)
    {
        // Perform your business logic here inside the object itself
        _Users.Add (User);
    }

    public UserGroup ()
        : this (null)
    { }

    public UserGroup (List<User> Users)
    {
        _Users = Users ?? new List<Users> ();
    }
}

Это помогает создать многофункциональный объект, сохраняет бизнес-логику внутри ваших объектов и избавляет вас от необходимости прибегать к созданию группы классов «Менеджер».

Answer 3

Вы также можете использовать фабричный шаблон.

например:

public class UserFactory
{
 public static List<User> GetUsers()
 {
 }

 //Optional method to get users in group from user factory
 public static List<User> GetUsersInGroup(int GroupID)
 {
  return UserGroupFactory.GetUsersInGroup(int GroupID)
 }
}

public class UserGroupFactory
{
 public static List<UserGroup> GetUserGroups()
 {
 }

 public static List<User> GetUsersInGroup(int GroupID)
 {
 }
}

Если в таблице User Group есть пользователь и ID группы, которые я положил, поместите его на фабрику UserGroup.

Answer 4

Как вы думаете, GetAllUsersForUserGroup(int UserGroupID) должно быть определено в классе, который управляет пользователями, или в классе, который управляет группами пользователей?

Этот метод должен быть определен в UserManager/ UserRepository class.

1. A Manager / Repository Класс обычно предназначен для набора аналогичных методов для работы с объектами конкретного класса, например, User class.

2. Эти методы включают методы для создания / запроса / извлечения из базы данных / кэша / локальной коллекции одного или нескольких объектов класса по некоторой спецификации.

3. Метод Get Users по спецификации UserGroup является одним из методов.

Наиболее простая реализация, если все пользователи хранятся в группе:

class UserRepository
    function GetUsers(Group as UserGroup) as IEnumerable(of User)
        return Group.Users
    end function
end class

или если все пользователи хранятся в одной коллекции:

class UserRepository
    private readonly UserCollection as ICollection(of User)

    public function GetUsers(Group as UserGroup) as IEnumerable(of User)
        return UserCollection.Where(function(U) U.Group.ID = Group.ID)
    end function
end class

Answer 5

Если вы получаете список пользователей, я бы поместил метод в класс Users, чтобы он читался естественным образом, например:

Users.GetAllByUserGroup()