Какъв трябва да бъде правилният контролер

Е, не. Моделът не е таблици или техните взаимоотношения. Това са данни и поведение (бизнес логика).
Не е нужно да вярвам, но Фаулър си струва да прочетете https://martinfowler.com/bliki/AnemicDomainModel.html

Ключовият момент тук е, че Service Layer е тънък - цялата ключова логика се крие в домейн слоя.

Като цяло, колкото повече поведение откривате в услугите, толкова по-вероятно е да се ограбите от предимствата на домейн модел.

Не знам защо този анти-модел е толкова често срещан. Подозирам, че това се дължи на много хора, които всъщност не са работили с подходящ модел на домейн, особено ако идват от фон с данни. Някои технологии го насърчават;
Рамките от вашия подпис наистина насърчават писането на анемични модели. Но това не е вярно. Бизнес логиката трябва да бъде в модели и само там. Услугата извиква само методите на модела, като по този начин променя състоянието му, запазва промененото състояние на модела в магазина, връща DTO за контролера и всякакви такива дребни утайки.

D3lphi: Моделът на домейна изобщо не трябва да зависи от рамката. Това е набор от обикновени POPO (обикновен стар php обект). Добре проектиран модел може да се изпълнява във всяка среда на всяка рамка, без да променя нищо в нея.

Ето защо написах, че тези рамки объркват всички карти и наричат ​​модел, който всъщност не е това, и хората започват да мислят, че тези анемични модели са нормални, че бизнес логиката в услугите е нормална. Но това не е така. Моделът е разработен от програмист. От нулата. Без рамково обвързване. В рамката изобщо не трябва да има никакви модели. Като в slimframework.

---