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

Question

[eugene159]

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

Answer 1

[Евгений Ромашкан]

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

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

Большинство даже в MVC никогда не пыталось разобраться, и думает что это когда в проекте 3 папочки есть(model/ view/ controller/).
Или что MVC было придумано для веб приложений (а это не так :) ).

Comments

[Антон Р.]

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

[Daria Motorina]

Евгений Ромашкан кажется ты упоминал про архитектуру 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... (вроде был и перевод на Хабре)

[eugene159]

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

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

[Евгений Ромашкан]

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

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

[Евгений Ромашкан]

eugene159,

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

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

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

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

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

[eugene159]

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

[Евгений Ромашкан]

eugene159,

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

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

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

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

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

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

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

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

Answer 2

[ThunderCat]

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

Answer 3

[Максим Грищенко]

Об архитектуре нужно обязательно почитать Робкрта Мартина: Чистая архитектура

Answer 4

[xmoonlight]

Во всех случаях, когда умеете строить архитектуру грамотно: есть полное понимание data work-flow.
Если не умеете - используйте MVC*.

Comments

[eugene159]

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

[xmoonlight]

eugene159, Подобный вопрос был про фреймворки на JS.
Я ответил так: "Если это ускорит скорость разработки не потеряв производительности и не усложнит дальнейшую работу с этим кодом - можно использовать фреймворк. В иных случаях - лучше всё писать на "чистом" JS/PHP".
Т.е., если возможно (есть запас времени/знаний) - лучше обойтись БЕЗ!

[alexkozlov1982]

Можете использовать middleware/pipeline при построении простых api сервисов или proxy frontend. Для php этот подход реализуют фреймворки zend expressive или slim