Классы менеджера - PullRequest
       7

Классы менеджера

3 голосов
/ 26 сентября 2008

В недавнем проекте, который я почти завершил, мы использовали архитектуру, которая в качестве верхнего уровня взаимодействия со слоями web / services использует классы XXXManager.

Например, существует служба Windows, которая работает по расписанию и импортирует данные из нескольких различных источников данных в нашу систему. В рамках этой службы несколько классов «Manager» называются, например, CPImportScheduleManager, CPImportProcessManager и т. Д.

Теперь эти классы Manager делают намного больше, чем просто передают метод по цепочке для использования в слоях web / service. Например, мой метод UserManager.Register () не только сохраняет пользователя с помощью сборок более низкого уровня, но также отправляет пользователю WAP-толчок и определяет используемую мобильную трубку и т. Д.

Мне было предложено, чтобы этот тип архитектуры был обычным способом попытаться привести ООП в соответствие с процедурной моделью. Я вижу их точку зрения здесь, но меня интересует то, что с этим набором классов верхнего уровня любой уровень web / service может просто вызывать один и тот же общий метод без необходимости переписывать код. Таким образом, если бы я хотел написать веб-сервис, который в какой-то момент зарегистрировал пользователя, я мог бы снова просто вызвать метод UserManager.Register () без необходимости переписывать всю логику снова.

Я никогда не был лучшим человеком, который мог бы объяснить себя, но если мои рассуждения имеют смысл, пожалуйста, не стесняйтесь давать советы по вашим альтернативам.

Ура, Крис.

Ответы [ 2 ]

7 голосов
/ 26 сентября 2008

Менеджеры - это часто используемая стратегия именования для служб, которые обрабатывают рабочий процесс или сложные задачи для данного набора объектов. Однако, если он выполняет свою работу, это не обязательно плохо.

Важный вопрос, который у меня возник бы: что происходит под менеджерами? Если они просто координируют рабочий процесс процесса, такого как регистрация пользователя, то они являются контроллерами (MVC) с другим именем. Однако, если они содержат много бизнес-логики (под этим я подразумеваю условную логику в зависимости от состояния сущности или набора сущностей), я бы внимательно посмотрел, можно ли сделать эту логику явной, делая ее собственный класс или перемещение его в класс с должной ответственностью.

Обновление: Судя по всему, у вас есть правильная идея в целом. У вас есть набор классов, которые управляют координацией ваших бизнес-процессов, которым все равно, используются ли они веб-сервисом, веб-формой или чем-то еще. Затем вы говорите, что хотите добавить свой слой WebService поверх этого и использовать эти классы. Это хорошая вещь (тм).

0 голосов
/ 26 сентября 2008

Похоже, ваша мотивация для этого дизайна была хорошей - повторное использование кода. В некотором смысле это похоже на мотивацию Уровень обслуживания Мартина Фаулера . Однако вы, возможно, вкладываете слишком много обязанностей в эти классы менеджера. Возможно, отделить инфраструктурные проблемы (WAP push, постоянство пользователей) от проблем домена (регистрация пользователей). Это Разделение проблем еще больше увеличит возможность повторного использования, а также улучшит ремонтопригодность.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...