Куда делегировать функции, которые являются частью контроллера, но слишком велики, чтоб оставлять их там?

Question

[Алексей Николаев]

Добрый день!
Допустим, есть метод регистрации, в котором кода строк на 200. Я раньше разбивал это на несколько методов (типа checkUser, addUser), которые находились в контроллере как приватные, однако это делало контроллер слишком толстым. Стоит ли выносить этот функционал в отдельный несвязанный компонент (библиотеку функций), или же стоит создать отдельный контроллер B, который будет реагировать на запросы контроллера А?

Буду благодарен за советы, спасибо.

Comments

[lyeskin]

Извините, а как checkUser и addUser , которые работают с базой ,относятся непосредственно к контроллеру? Почему бы не вынести их в модель ,а остальное в хелперы ?

Answer 1

[Сергей Протько]

организуйте сервисный слой приложения.

Answer 2

[Максим]

Контроллер не должен в себе содержать логики, кроме извлечения вводимых пользователем данных, его обработки с помощью сервисов или моделей (на самом деле тут может быть какой угодно слой, вариантов масса) и ответа. В вашем случае есть два популярных подхода к решению задачи:

• MVC - логика здесь будет находится в основном в модели. Достаточно простой и очевидный способ для новичков в ООП.
  
• SOA (ссылка не очень удачная, но думаю смысл должен быть понятен) - способ для более опытных разработчиков, но и более гибкий и востребованный в больших приложениях со значительным сроком разработки и поддержки.
  

Для SOA вам действительно необходим будет DependencyInjection Container (или ServiceLocator), который новичкам достаточно сложно освоить. В MVC подходе все намного проще и очевиднее, поэтому рекомендую сначала попробовать его, а потом, когда упретесь в толстые модели, переходить к SOA и использовать сервисный слой.

Comments

[Сергей Протько]

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

2) SOA это несколько другое, тут сервисы это самостоятельные приложения а не какие-то классы-службы. Очень часто путают это дело.

[Сергей Протько]

по SOA почитайте про микросервисы, про гексагональную архитектуру...

[Сергей Протько]

fideloper.com/hexagonal-architecture
https://www.youtube.com/watch?v=ajhqScWECMo

[Максим]

Сергей Протько: Давайте не будем человека путать, по его вопросу понятно, что с проектированием он еще не знаком =) MVC проще всего освоить на одной модели, на фрейморках типо Yii, где модель явно выражена. Понятное дело, что Вы можете вынести логику в сервисный слой, но работая над маленьким приложением или прототипом в этом нет смысла.
А насчет SOA, вопрос не в конкретной реализации, а в самом принципе независимых и инкапсулированных сервисов. Это актуально и в проектировании одного приложения. Ссылка не удачная, как и термин SOA, но этот способ является хорошим примером, как нужно проектировать своё приложение. Я наверно не правильно донес свою мысль =)

[Сергей Протько]

Максим: в том то и вопрос что люди под "моделью" быстро начинают понимать их любимые сущности предоставляемые их любимыми ORM и потом переучивать довольно тяжко.

Я привел ссылку на неплохой доклад, в котором обзор различных подходов, от тупого круда с толстыми контроллерами до CQRS.

[Сергей Протько]

Максим: а идея "инкапсулированных сервисов" - тут больше подходят ссылки на слоеные архитектуры, onion architecture, hexagonal architecture и т.д.