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

Question

[GrimJack]

Пишу приложение на laravel и встал вопрос. Куда лучше выносить одинаковую логику для разных частей приложения? Делать "родительскую" модель/контроллер и в нужном месте наследовать его, считаю глупостью. Куда правильнее вынести такие вещи?
Например в хэлпер я выношу небольшое функции типа isJson и тд. Которые могут быть востребованы в любом участке приложения и не должны выполнять каких-то особых функций.
А как быть с массивными вещами? Например, фильтрация двух сложных элементов с наложением между собой. Не думаю, что валить все это в хэлпер хорошо.
Да и вообще, куда вы предпочитаете выносить "тяжелую" логику в приложении? Что-бы не делать жирных контроллеров и не захламлять модели?

Comments

[Anton Kuzmichev]

GrimJack, вы удалили свой вопрос про права пользователей, и я не смог отправить вам коммент, поэтому отправляю сюда:

Совсем малой кровью можно отделаться, сменив формат хранения чисел "через запятую" на подобный:
[0][5]
Основная идея - каждое число обрамлено какими-нибудь скобками, искать вхождения можно с помощью:

permission_group LIKE "%[0]%" OR permission_group LIKE "%[5]%"

[FanatPHP]

Anton Kuzmichev, вот зачем демонстрировать свое дремучее невежество и тащить это ламерское адище из прошлого века, с ненормальными базами данных, лайками и ручным ковырянием в SQL?

[Anton Kuzmichev]

FanatPHP, вот зачем демонстрировать своё нетерпение при абсолютном непонимании ситуации и тащить некое непонятное ламерское адище с ненормальными репликами, комментариями и ручным ковырянием в носу?
https://toster.ru/answer?answer_id=554481

Answer 1

[Саня Технадзор]

Всегда старайтесь смотреть на "старший" фреймворк откуда все это дело портируется с первого дня создания laravel. (в хорошем смысле без холиваров).

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

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

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

UPD собвстенно в рельсах для этого есть концерны, хелперы для другого - но в вашем случае хелперы помогут если не делать "свои" концерны как я указал.

Comments

[Вадим]

Я думал, что вы про symfony.

Answer 2

[heartdevil]

У вас, походу, это вообще бизнес логика. Нужен слой сервисов.

Comments

[FanatPHP]

В Симфони сервисами является вообще всё - контроллеры, хелперы, репозитории.И все реализуют бизнес-логику. Что делает этот ответ чуть более бессмысленным, чем полностью.

[mitaichik]

FanatPHP, А что такое сервис с вашей точки зрения? Особо не знаком с симфони, но ваше высказывание кажеться крайне сомнительным.

[heartdevil]

mitaichik, и я не знаком. Но знаком с asp.net в частности c#. И вот там мы оргинизовывали классы-сервисы выстроенные через интерфейсы, которые были ответственны "только" за бизнес-логику. А из контроллеров мы обращались к этим сервисам. Под сервисами был слой репозитариев. Если в симфони под хелперами понимается тоже слой, то да, разницы никакой. На других проектах были статические классы-хелперы (где-то их менеджарами называют, но суть одна). Вот у меня на это ассоциация сработала.

[mitaichik]

heartdevil, я с вами полность согласн, мои, так сказать, возмущения, вызваны комментом FanatPHP. Просто сервис (служба) - объкт без обозначенного жизненного цикла какторый выполняет какую-то работу в рамках бизнес-логики не меняя при этом внутреннего состояния. Все быть сервисам не может.

Если ты получаеш что-то через Service Locator - это не значит что то что ты получаеш является сервисом в понимании бизнес-логики.

Answer 3

[FanatPHP]

Почему нехорошо? Что конкретно "нехорошего" в создании хелпера, реализующего определенный сервис и предоставляющего этот сервис различным частям приложения?

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

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

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

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

Модель - самое неудачное слово, которое существует в мире веб-разработки.
Хелпер является полноправной частью модели. А то что ты называешь моделью - слой работы с БД - это либо DBAL, либо ORM, дата маппер.
Чтобы не захламлять маппер, тебе нужен репозиторий. Тот же хелпер, но работающий с БД, коллекция специфичных SQL запросов.

Answer 4

[mitaichik]

Да куда угодно. То что вы описали (isJson и т.п.) - имхо им место как раз в хелперах. А так - все завсист от функционала. Сервисы, репозитории, агрегаты, вылидаторы, поведения, трейты, филтры, фабрики, билдеры, адаптеры и т.п. - список огромный

Comments

[FanatPHP]

Смешались в кучу кони, люди...

[mitaichik]

FanatPHP, тут лишнее разве что трейты, ибо это элемент реализации, а не элемент бизнес-логики

Answer 5

[ajaxtelamonid]

Вспомните, что вы пишете не на фреймворке, а на PHP. Делайте классы и пишите весь нужный функционал там. Благо, в Laravel позволяет подключать классы в аргументах конструктора контролера, команды и т.п. Называйте классы так, чтобы вам потом было понятно. Размещайте их в папке Services, например, или в папках, названных по функционалу приложения - Orders, Invoices и т.п. - как вам удобнее.

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