Перейти к содержанию

Контроллер (Controller)

Controller рекомендует принимать внешний запрос через объект-координатор сценария, а не размазывать orchestration по низкоуровневым участникам.

Важно: это не то же самое, что контроллер в MVC. В GRASP речь идет не о конкретном UI-слое и не об элементе фреймворка, а о роли объекта, который принимает внешний запрос и координирует выполнение use case.

Опора на ООП

Controller опирается на инкапсуляцию и низкую связанность: координация use case отделяется от доменной логики и от деталей интерфейса.

Что показывает пример на 1С

  • форма вызывает SalesOrderController.Post(...), а не пытается сама загрузить объект, проверить данные и провести документ.
  • контроллер управляет сценарием целиком: загрузка, заполнение, проверка, запись.
  • доменные объекты и форма остаются проще и не смешивают UI с orchestration.

Пример

&AtClient
Procedure PostCommand(Command)

    CommonModules.SalesOrderController.Post(Object.Ref);

EndProcedure
Procedure Post(SalesOrderRef) Export

    SalesOrder = SalesOrderRef.GetObject();

    SalesOrderValidation.CheckBeforePosting(SalesOrder);
    SalesOrder.Write(DocumentWriteMode.Posting);

EndProcedure

Близость к MVC Controller

Термины похожи, но смысл разный.

  • MVC Controller обычно относится к архитектуре пользовательского интерфейса и управляет взаимодействием между представлением и моделью.
  • GRASP Controller отвечает на вопрос: кто должен принять внешний системный запрос и собрать сценарий выполнения.

В 1С это особенно важно, потому что роль GRASP Controller могут играть очень разные точки входа:

  • общий модуль, который координирует проведение документа;
  • обработчик HTTP-сервиса;
  • серверная процедура команды формы;
  • координатор фонового задания.

То есть GRASP Controller не обязан быть "контроллером экрана". Это просто объект или модуль, которому доверили orchestration конкретного сценария.

Где полезен в 1С

  • в командах форм, HTTP-сервисах и фоновых заданиях;
  • для сценариев создать / проверить / провести / отправить;
  • когда важно отделить use case от деталей интерфейса и хранилища.

Когда принцип применяют неправильно

  • если контроллер превращается в "бог-объект";
  • если он начинает хранить доменное состояние вместо координации сценария;
  • если вся бизнес-логика выносится только в контроллер, а доменные объекты пустеют.