В каких случаях при разработке сайта на PHP лучше использовать не MVC (и его подобия), а какой-нибудь другой подход?

А где почитать про Истинную Суть MVC а не про папочки?

Евгений Ромашкан кажется ты упоминал про архитектуру ADR (action domain responder) - которая реально для веба создана

Антон Р., Первоисточники)
folk.uio.no/trygver/2007/MVC_Originals.pdf
Чтобы понять что в современной трактовке что-то не так можно хотя бы долистать до определения model view и controller.
1979 год, если что.
Ещё такое есть - https://badootech.badoo.com/do-mvc-like-its-1979-d... (вроде был и перевод на Хабре)

В случаях когда разработчики проекта разбираются в разных подходах и знают какой лучше использовать.
Во всех остальных случаях лучше этого не делать.

Даже если я пишу не сайт, а веб сервис, который состоит из одной страницы, получает данные по API и формирует отчет в Excel? Это все можно вообще в одном php файле написать. Но стоит ли? Или лучше все же MVC? И если лучше, то почему?

Daria Motorina, И туда-же MVA который так же mediating-controller MVC.

На самом деле суть в том что это не так важно.
Если нет четкого представления что есть MVC(или любая другая модная штуковина) пытаться найти какие-то каноны чтобы им следовать - так себе затея.

eugene159,

Даже если я пишу не сайт, а веб сервис, который состоит из одной страницы, получает данные по API и формирует отчет в Excel? Это все можно вообще в одном php файле написать. Но стоит ли?

Этого мало чтобы принять решение.
Архитектура нужна чтобы упростить и тем самым удешевить дальнейшую разработку ПО.

Если дальнейшей разработки не будет - она может быть и не нужна(на самом деле все-равно нужна потому что в будущее мы заглядывать не умеем). Городить что-то сложное вряд ли стоит.

Если скрипт не планируется активно расширять дальше - хватит просто написать его понятно, ну например, входная точка(1 класс) + гейтвей (получатель данных) к api и Presenter(класс, формирующий отчёт), с адекватными названиями переменных и методов(кода вместе с классами выйдет меньше сотни строк скорее всего, затраты времени минимальны.

Да, такой скрипт даже заново легко будет написать, но нюансы всегда могут непредвиденно возникнуть - например, утеря спецификации API, и придется копаться в старом коде чтобы понять что и в каком формате оно отдаёт.
Лучше сразу сделать +- понятно.

Евгений Ромашкан, спасибо. Про MVC я понял. А что касается фреймворков? Также лучше стараться использовать в большинстве случаев фреймворки? Даже если сайт - это одностраничный сервис?

eugene159,

Также лучше стараться использовать в большинстве случаев фреймворки?

Да правило снова то же: Лучше всего знать разные инструменты и подбирать инструмент под задачу, ну и стараться совершенстовать навыки и знание инструментов с опытом.

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

В ином случае придётся делать "как умеешь", как умеет разработчик/команда, или как уже выстроены процессы. Но знать хотя-бы один фреймворк на уровне пользователя уже обязан по сути каждый джун.

Даже если сайт - это одностраничный сервис?

Если конкретно, то да. Фреймворк=каркас, и он будет всегда, готовый или написанный самому. Писать фреймворк для небольшого сайта самому конечно же не нужно.

Для простых сайтов аля "наш бложик" часто просто берут людей которые знают какой-нибудь wordpress чтобы он быстро и дёшево сделал что нужно. Ведь сильно кастомизировать такое вряд ли понадобится.

Выходя за рамки фреймворков, если на backend не нужно много логики - есть, например, решения типа firebase/prisma/PostgREST, которые из коробки представят интерфейс над базой данных, оставляя разработчикам задачу написать нужный им фронтенд, но это уже не мейнстрим, не особо популярно.