Почему в вебе модель в MVC аки феникс?

Можно и долгоживущие объекты держать, не вопрос. Но это затруднит быдлокодинг, будут нехилые утечки и гонки. В вебе с начала времен зарекомендовала себя схема «отстрелялся и умер», конечно накладные расходы нехилые, зато просто и безопасно. Я помню в mod_perl мы расшаривали долгоживущие данные, все было супер-быстро, но в итоге мало кто с этим умел работать.

Короче, вебщики выбрали кеширование на уровне страниц и фрагментов вместо сложных техник кеширования объектов бизнес-логики.

В вебе

cgi и php это не весь веб.

Да ладно не весь. Ну и всякие тредпулы работают концептуально точно так же.

Какие тредпулы? В мире веба на питоне, руби, ноде, да чем угодно у тебя сервер это демон, который весит в памяти и обрабатывает запросы, а не перезапускается на каждый запрос. Вот, например, змейка https://habr.com/ru/post/346696/ как видишь, у нее общие данные между несколькими соединениями.

Потому что модель в MVC является моделью только с точки зрения PHP. А с точки зрения всего проекта M это прослойка между настоящей моделью (БД) и контроллером. По сути то что ты называешь моделью на самом деле драйвер модели, которой на самом дел является БД, а она живет постоянно, что для модели вполне правильно, как ты правильно замечаешь.

Все правильно - 99% это не целое.

Ну и что, что висит в памяти. На каждый запрос порождается туча объектов, которые потом чистит GC. Никто не проектирует долгоживущие объекты, ну или мало кто это делает.

Потому что PHP создан, чтобы умирать

Можно кешировать на уровне запросов к базе, где самые как раз затыки. Все упирается только в кривизну рук кодера и орма, который норовит наплодить много лишних запросов и 100500 объектов. Если выкинуть все ненужно, писать ручками каждый запрос и тщательно контролировать количество и время жизни объектов, то можно и долгоиграющую модель забабахать на манер настоящей MVC.

общие данные между несколькими соединениями

Как будто это что-то хорошее.

возможно, мне стоит смотреть в сторону ноды... Или нет?

Можешь попинать очевидные ReactPHP или Workerman. Но зачем? Изоляция VM в каждом запросе это фича.

держать модель живой постоянно

Зачем? Кэш можно сделать явно и отдельно.

Потому, что ActiveRecord — не совсем модель, а в вебе моделью обзывают именно этот паттерн. Если тебе так проще, можешь считать моделью БД.

Куда более производительным бы было держать модель живой постоянно

А потом тебе захотелось обработать >1 запроса параллельно. Как ты 1 экземпляр модели между ними поделишь?

Классический (включая php) веб — про вытаскивание state в базу (кэши — тоже база если что).

К примеру, для джанго есть автоматическое кеширование с автоматической инвалидацией https://django-cachalot.readthedocs.io/en/latest/ в debug toolbar видно какие запросы были сделаны, чтобы сгенерить страницу, их количество легко уменишить, сказав orm сделать нужные джоины или prefetch

Весьма. Кроме очевидных приложений на вебсокетах и прочих чатиков, например, у меня в телеграм боте ограничение на слишком частые запросы. Это просто хэш таблица со временем последнего запроса. Использовать тут что-либо внешнее сервис был бы оверкилл. И таких вещей масса.

Блокировка выполнения, пока другой поток не сделает там .save. Наоборот более логично, чем 2 паралельных запроса с двумя экземплярами модели, один из которых уже устарел т.к. другой запрос ее изменил и перезаписал. И первых работает со старыми данными и их сохраняет. И тут еще разные варианты могут быть развития событий т.к. некоторые orm сохраняют все, некоторые только измененные поля.

На данный момент занимаюсь проектом на PHP и вот после тяжёлого дня в голову пришла мысль, а почему собственно в паттерне MVC модель не живёт постоянно, а умирает и возрождается заново каждый раз при запросе к серверу?

потому-что так работает пэхапэ

Это просто хэш таблица со временем последнего запроса. Использовать тут что-либо внешнее сервис был бы оверкилл

Это можно просто положить в mmap или shmem и будет точно также как «что-то внутреннее».

на вебсокетах

long polling вид сбоку.

php рожден чтобы умирать (c)

а php - это фреймворк, изначально написанный на perl. вот он из мира perl, где cgi, тот древний протокол http/1.0, где закрывалось соединение после любого запроса. на php можно демонов писать, но нужно ли? (они текут). я знаю извращенцев из topface, которые для бузовой бузкойн разрабатывали. вот у них там все на php, даже небо и даже аллах... до того как в php 7 появились треды, они симулировали их... пхпшники все извращенцы. я рад что больше не пишу на php (я на нем писал с 2009 по 2017). сейчас пишу на python 3.

Блокировка выполнения, пока другой поток не сделает там .save

Или другой хост, ага.

на дворе 2019 год

В этом нашем 2к19 году в моду среди хипстеров входят FaaS-платформы, которые (сюрприз!) умеют в том числе запускать функцию, для которой вообще всё умирает и возрождается каждый запрос. И это позволяет как обрабатывать десятки, тысяч, сотни тысяч запросов параллельно (не путать с event-driven, где запросы дожидаются друг друга), так и экономить ресурсы (и деньги!) когда нагрузки нет. И всё это — только потому, что они stateless.

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

можно и долгоиграющую модель забабахать на манер настоящей MVC

Можно, но вопрос был почему так не делают. И как бы я на это и попытался ответить - долгоиграющая модель в вэбе это и есть БД, а та модель что в MVC - это прослойка.

Можно конечно взять и написать какой-то прибабас к БД который будет реализовывать все эти ОРМы на стороне БД и ... в MVC все равно остается какая-то модель в виде кастомизаций и вопрос опять сведется - «почему модель в PHP не живет вечно?»

Мы можем впиливать сколь-угодно высокоуровневые фичи в БД, но в MVC будет какая-то связка с БД и именно ее назовут моделью и спросят почему она не живет вечно.

Очнитесь - у вас и так уже SQL на стороне кей-волуе хранилища, а не в PHP

Потому что веб - для страниц.

ни что не мешает держать модель например как микросервис (REST), дальше зависит от реализации ...

почему собственно в паттерне MVC модель не живёт постоянно, а умирает и возрождается заново каждый раз при запросе к серверу?

Потому что HTTP/2 придумали совсем недавно.

Раньше в HTTP 1.0 не было смысла держать модель, так как каждый запрос сам-по-себе.

Сессии, которые появились в HTTP 1.1 (с keep-alive) - они уже лучше, но как-то там это не прижилось, рекомендуют у них время жизни маленькое ставить - отработали одну страницу и её картинки в одном соединении и закрываем.

В HTTP/2 уже (наверное) имеет смысл держать сессию на сервере долго, чтобы из неё можно было высылать push-уведомления. Да и то не факт.

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

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

MVC и PHP живет потому что это надежное (простое) решение имеющее достаточную производительность для 99 из 100 случаев если у вас на стороне ORM все в порядке с кешированием. Если положить модельки (как правило это просто дтошки) в какой нибудь редис и завести систему инвалидации по тегам то получаеш как раз почти эти самые вечно живущие модели (сериализация и десериализаця в PHP очень быстрая) не теряя надежности MVC. Это не рокет сайн, это дешевле, это подходит для подавляющего большинства задач, поэтому это живёт.

а профит то какой? лишнее звено в цепи получения/модификации данных с лишней сериализацией/десериализацией и накладными расходами на взаимодействие, захват блокировки, проверку, инвалидацию.

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

а профит то какой? лишнее звено

Это всего лишь более независимый утонченный слой абстракции данных.

в цепи получения/модификации данных с лишней сериализацией/десериализацией

Расходы есть везде, не увлекаться же подменой в конце концов V на M, хотя все относительно - V для клиента может являться той-же моделью.

Триада MVC как правило может неявно присутствовать в каждом слое и вообще полезно так рассматривать для простоты ...

В конечном итоге все модели трансформируются как правило в точечное распихивание по полям слотов View. Кстати, где вы там нашли сериализацию, если модель персистентна? Расходы есть на передачу - да.

и накладными расходами на взаимодействие, захват блокировки, проверку, инвалидацию.

Это работа для контроллеров как правило.

на PHP
не живёт постоянно

This.

интересует мэйнстрим

Java, асинхронные фреймворки на питоне.

Писать на интерпретаторе шаблонов

@

Париться о паре лишних объектов на запрос

На Sanic? Судя по аватарке :)

Писать на интерпретаторе шаблонов

Это он изначально был интерпретатором шаблонов, а стал полноценным ЯП с интерпретатором искаропки. Другие языки пошли иным путём - сначала стали полноценными ЯП, а потом сбоку прилепили интерпретаторы шаблонов. Как по мне - не велика разница, как шла история, гораздо важнее, - как дела обстоят на текущий момент.

Ключевое слово «интерпретатор» :) К тому же динамически типизированный. Просто нет смысла рассуждать о производительности когда вместо програмы пишешь сценарий для строкового проигрывателя

Просто нет смысла рассуждать о производительности когда вместо програмы пишешь сценарий для строкового проигрывателя

Питон вышел в топ ЯП, хотя тоже - строковой проигрыватель.

Существует JIT, это не аргумент ни для питонов, ни для php.

Как связан топ языков и производительность?

А вообще мне непонятно как питон занял столь высокое место. Сейчас приходится писать интеграцию для home-assistant. Плююсь

А все потому что нет аннотаций типов у функций. Декларации вроде

def create_elk_entities(hass, elk_elements, element_type, class_, entities):
    ...

Еще не все предваряют приватные поля нижним подчеркиванием, что тоже добавляет радости

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

в 3.5 аннотация появилась

Я-то использую. А вот другие на используют. Ты используешь?

машин ленинг и дата сосаенс

... без статического анализа. Вот так и появляются скайнеты

Аннотации есть, в более старых версиях их записывали в docstring и ide это понимают. Как и mypy.

Для стороннего кода есть stub файлы, если авторы кода их не написали их можно автоматически нагенерить через monkeytype. Да оно и без аннотаций догадывается https://imgur.com/a/tvhMZjq

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

В последних 3-х местах работы аннотации везде были. Короче ты сказал что их нет, а выяснилось что тебе просто лень, проще наговнокодить кое-как.

Навскидку открыл сорцы Django, Flask и Requests

https://github.com/django/django/blob/master/django/http/request.py

https://github.com/pallets/flask/blob/master/flask/sessions.py

https://github.com/requests/requests/blob/master/requests/models.py

Аннотаций нет. Докстринги есть (не всегда) в публичных методах, но типы в них не описаны

https://github.com/python/typeshed/tree/master/third_party/2and3/requests например. если в django их (пока) нет, это не значит что ты в своем коде не можешь их использовать.

она не везде нужна. в библиотеках под asyncio нотацию часто использует.

Куда более производительным бы было держать модель живой постоянно

Этот подход не масштабируется на большое количество пользователей, тупо памяти не хватит

стал полноценным ЯП

ну-ну