Куда лучше помещать одинаковую логику для разных контроллеров/моделей?

Пишу приложение на laravel и встал вопрос. Куда лучше выносить одинаковую логику для разных частей приложения? Делать "родительскую" модель/контроллер и в нужном месте наследовать его, считаю глупостью. Куда правильнее вынести такие вещи?
Например в хэлпер я выношу небольшое функции типа isJson и тд. Которые могут быть востребованы в любом участке приложения и не должны выполнять каких-то особых функций.
А как быть с массивными вещами? Например, фильтрация двух сложных элементов с наложением между собой. Не думаю, что валить все это в хэлпер хорошо.
Да и вообще, куда вы предпочитаете выносить "тяжелую" логику в приложении? Что-бы не делать жирных контроллеров и не захламлять модели?
  • Вопрос задан
  • 2023 просмотра
Пригласить эксперта
Ответы на вопрос 5
apavlyut
@apavlyut
www.pavlyut.ru
Всегда старайтесь смотреть на "старший" фреймворк откуда все это дело портируется с первого дня создания laravel. (в хорошем смысле без холиваров).

Долгое время в rails я просто выносил общую логику в модули, не знаю как сейчас конкретно это делается в php, но концептуально это просто все набор функциональных методов (не содержащих состояния) объединенных в неймспейс - фактически это может быть и класс любой.

В общем делается инклюд и пользуешься.

Говоря про рельсы в итоге там для этой функции появились концерны - что будет в laravel для этого неизвестно, но можно просто смело использовать функциональные классы. (функциональное программирование)

UPD собвстенно в рельсах для этого есть концерны, хелперы для другого - но в вашем случае хелперы помогут если не делать "свои" концерны как я указал.
Ответ написан
@heartdevil
плыву как воздушный шарик
У вас, походу, это вообще бизнес логика. Нужен слой сервисов.
Ответ написан
FanatPHP
@FanatPHP
Чебуратор тега РНР
Почему нехорошо? Что конкретно "нехорошего" в создании хелпера, реализующего определенный сервис и предоставляющего этот сервис различным частям приложения?

Делать жирный хелпер и захламлять его не связанными друг с другом функциями - это действительно нехорошо. Но никто же и не принуждает иметь единственный хелпер на все приложение.

куда вы предпочитаете выносить "тяжелую" логику в приложении? Чтобы не делать жирных контроллеров

В хелперы. Они именно для этого и предназначены

> не захламлять модели?

Модель - самое неудачное слово, которое существует в мире веб-разработки.
Хелпер является полноправной частью модели. А то что ты называешь моделью - слой работы с БД - это либо DBAL, либо ORM, дата маппер.
Чтобы не захламлять маппер, тебе нужен репозиторий. Тот же хелпер, но работающий с БД, коллекция специфичных SQL запросов.
Ответ написан
Комментировать
mitaichik
@mitaichik
Да куда угодно. То что вы описали (isJson и т.п.) - имхо им место как раз в хелперах. А так - все завсист от функционала. Сервисы, репозитории, агрегаты, вылидаторы, поведения, трейты, филтры, фабрики, билдеры, адаптеры и т.п. - список огромный
Ответ написан
ajaxtelamonid
@ajaxtelamonid
Laravel
Вспомните, что вы пишете не на фреймворке, а на PHP. Делайте классы и пишите весь нужный функционал там. Благо, в Laravel позволяет подключать классы в аргументах конструктора контролера, команды и т.п. Называйте классы так, чтобы вам потом было понятно. Размещайте их в папке Services, например, или в папках, названных по функционалу приложения - Orders, Invoices и т.п. - как вам удобнее.

Классы пишите по принципу SOLID, чтобы они были узкоспециализированными, слабо связанными друг с другом и т.п.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
28 мар. 2024, в 21:17
5000 руб./за проект
28 мар. 2024, в 20:46
150000 руб./за проект
28 мар. 2024, в 20:37
50000 руб./за проект