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

и при этом все это еще и имело разные назначения. работало и с excel и выдавало json, и формировало html

тут скорее дело не в том, что это невозможно обновлять и улучшать

а в том, что вместо двух недель можно было сократить до пары дней максимум

Можно конечно, но здесь явное нарушение ответственности. А тема которую мы рассматриваем говорит лишь о логике которая относиться к модели непросредственно. Если не относиться, то можно внедрить новую сущность.

Всем привет :) У меня тут сложилась интересная ситуация с архитектурой. Прям такое оопэшное ооп, как в учебниках. Буду рад любой помощи/советам/критике.
Проблема:
На сайте есть несколько (около 10) типов транзакций. Для простоты будем считать, что их 2 - букинг машины и букинг отеля. После успешной транзакции надо отправить по емейлу админу и кастомеру (назовем это "таргетом"). Емейлы очень сильно разнятся, в зависимости от типа транзакции и таргета.
Есть код, который позволяет сгенерировать нужный емейл. На каждый тип транзакции создается свой класс, который экстендит общий класс транзакционного емейла (ларавелевский мейлабл). В нужных классах сеттятся необходимые параметры и в конце отдается необходимая вьюха. И есть еще фактори класс, который определяет, какой именно мейл класс нам нужен.
Но потом оказалось, что транзакции принадлежат разным партнерам, и некоторые из них не хотят себе стандартный лейаут писем. Собственно, в этом и задача - как покрасивше реализовать генерацию кастомных емейлов?
Первое, из наименее блевотных вариантов, что мне пришли в голову, это на каждого привередливого партнера создать свой кастомизейшн класс, в котором будут сеттиться кастомные параметры (путь к кастомному темплейту, в самом просто варианте). Но реализация вышла такая себе.
Я одним местом чую, что тут подойдет какой-то паттерн, но я в этом не очень силен.
Код (весь мусор выкинул, офк): https://paste.laravel.io/efcdda58-332a-4862-966a-de5ffbb2645c#

как один из вариантов

Привет. Позавчера с Вячеславом и Мрякой был интересный разговор про то, как лучше организовывать код. Раньше я использовала подход с вынесением БД в сервисы, но он у меня плохо вписывался в лару. Попробовала переделать 1-ин небольшой проект под то, что предлагал Вячеслав - большая часть БЛ в моделях с трейтами, новые сущности при необходимости определенного функционала, действия над объектами(вместо объект что-то делает). И мне в принципе нравится - стало меньше кода и он упростился. Такой способ организации кода очень хорошо подходит к тому как построена лара, и поэтому не приходится "бороться" с фреймворком. Это просто мысли в слух, буду наблюдать, как такая методология будет работать, когда проект начнет расти.

Ну так делись...

Спасибо за фидбек, будет интересно наблюдать вместе с тобой

👍👍

https://github.com/annya-a/laravel-feedback-tracker - вот проект. Дисклеймер: я не являюсь опытным разработчиком именно с ларой, поэтому не следует воспринимать мой код, как best practice 🙃

Постоянно, глядя на твою аватарку, вспоминаю времена появления мульта Simon's cat :)

Да, мультик классный)

кто-то mailhog юзает?

да

сейчас даже открыт

в чем вопрос?