mvc допустимо следующее поведение?

Да, можно. Обычно создание новой и редактирование существующей записи может быть одним и тем же методом, или вызывать один и тот же метод контроллера. Но не нужно сильно увлекаться и размещать весь код в контроллерах и потом вызывать один контроллер из другого.

Не дублировать же код

Этот код не нужно дублировать, его нужно ставить в модели.

Если в контроллере есть некие вызовы общие для нескольких действий - эти методы нужно выносить в класс-сервис и получать его в качестве зависимости для повторного переиспользования. Если у тебя в контроллере один экшн вызывает другой экшн - стоит задуматься о качестве композиции, что то тут нет так. Пихать код в модели не нужно. Ты конечно можешь это сделать, но жирные модели с како-либо логикой это не есть хорошо. По возможности выноси логику в сервисы. Модели только для работы с БД. Контроллеры только как запускалка каких либо действий в сервисах. Виды только для вывода, хотя в PHP мире виды в большинстве случаев это тот еще трэш.

Пихать код в модели не нужно.

Что?

По возможности выноси логику в сервисы.

Что, !@#$%?

То. Ты путаешь модель в dbms и модель предметной области, которой место в сервисах в соответствии с single-responsibility

Это все ява-петушня

Что конкретно тебе разжевать?

Это все ява-петушня

Ясно. На предыдущий вопрос можешь не отвечать.

Но не нужно сильно увлекаться и размещать весь код в контроллерах и потом вызывать один контроллер из другого

вызывать один контроллер из другого

Этим не то чтобы не нужно увлекаться. Этого делать нельзя (ну макакам то можно). К слову - совсем!

Если в контроллере есть некие вызовы общие для нескольких действий - эти методы нужно выносить в класс-сервис.

Кажется в PHP это называется trait.

Трейты - это единственное, что мне на самом деле искренне понравилось во всём этом мраке с ООП и MVC на PHP.
Такой чудесный шаблонизатор страничек был.

Просто мимо проходил тут.

Трейты тут вообще не при делах. Трейт вообще не должен отвечать за логику или поведение приложения. Понимаешь почему?

Трейты должны служить тем классам, у которых гарантировано при инстансе происходит обращения ко всем методам этих самых трейтов. Но в реальности, особенно благодаря всякому говну вроде Laravel (который пихает это везде где только можно и нельзя), в трейты начинают пихать все что не поддается осмыслению.

Ну и конечно, самое главное - как это все тестировать? Создавать мок класс и заюзать трейт? Значит трейт должен быть публичным - верно? Но ведь ты понимаешь что это значит? А значит у тебя в классе который использует трейт есть публичные методы которые имеют логику (хорошо если это не так) или ее часть или что угодно еще.

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

Если таки ты потрудишься прочитать тс и комментарий на который я ответил, то поймешь, что речь шла именно о дергании методов. О том как это используется в разных фреймворках мне известно. Каждый день делаю код ревью разной степени понимания программиста котрый сделал MR о том для чего и как он использует те или иные возможности языка (речь о PHP в данном случае).

Эммм.. ) Пардон, я не готов спорить.

Конечно, вы наверняка правы.

Просто так запомнилось. Мучительно рожал ООП на голом PHP. По сути - только ради того чтобы выпендриться модными «контроллерами». Выпендриться исключительно перед самим собой, т.к. заказчикам вообще фиолетово как оно там внутри работает.

Всё равно вся логика внутри PostgreSQL в хранимках.

Когда всё заработало - захотелось еще и AJAX прикрутить. И трейтом его влепить в уже готовую структуру оказалось очень просто и удобно. Конец истории )

гарантировано при инстансе происходит обращения ко всем методам этих самых трейтов

реализацию какого либо интерфейса

Ну и это как бы намекает, не так ли? Если нет, то имплементация интерфейса говно.

Намекает только все наоборот - трейт использует методы класса если это нужно

Вот пример вспомнил из симфони

https://github.com/symfony/dependency-injection/blob/master/ContainerAwareTra...

class MySuperPuperCommand implements ContainerAwareInterface
{

use ContainerAwareTrait;

И? Хотя твой слив засчитан. Вернее не слив, а фгм.

А у тебя умственная диарея из-за чсв

можно ли вызывать другие методы класса A в этом же методе

При чём тут mvc?

Не дублировать же код, делая действия других маршрутов из модели

Ещё раз, при чём тут mvc? У тебя с декомпозицией жопа.