LINUX.ORG.RU

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

 , ,


1

2

На данный момент занимаюсь проектом на PHP и вот после тяжёлого дня в голову пришла мысль, а почему собственно в паттерне MVC модель не живёт постоянно, а умирает и возрождается заново каждый раз при запросе к серверу? Ведь, по-идее, это очень не выгодный подход. Куда более производительным бы было держать модель живой постоянно, а легковесные контроллеры - не так уже трагично будет создавать по запросу, ну а с вьюхами ничего не поделаешь - их в любом случае нужно перестраивать под каждый чих (я сейчас про кеширование намеренно не заикаюсь, чтобы не усложнять). Я понимаю, что концепция PHP не располагает, чтобы что-то там долго жило, но ведь, вашу медь, на дворе 2019 год... Я помню, разрабатывал под .NET (начиная с WebForms - но то мрак совсем, и заканчивая MVC), так вот, под дотнетом, который имеет ну очень развитую инфраструктуру, всё происходит точно также как в пыхе - модель создаётся по мере надобности и дохнет после того, как обслужила очередный хотелки контроллера на запрос юзера... и так десятки, сотни, тысячи раз в единицу времени. Доколе, спрашивается? Или, может, я что-то упустил, и в мейнстриме есть что-то, что работает иначе? Я догадываюсь, что, возможно, мне стоит смотреть в сторону ноды... Или нет? Подскажите, пожалуйста. P.S. Не надо приводить в пример технологии, которыми пользуются три с половиной человека. Я за них искренне рад, но меня интересует мейнстрим. Заранее благодарю.

Deleted
Ответ на: комментарий от annulen

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

Deleted
()
Ответ на: комментарий от annulen

ну-ну

Он местами уродский, местами костыльный, по причине долгой истории и особенностей в развитии, но тем не менее... в нём есть и процедурщина и ООП в полном объёме, ну и зайчатки функциональщины, как это принято во многих современных ЯП: лямбды, замыкания, функции как first class citizen и всё вот это. И не смотря на то, что родился он как шаблонизатор для веб страничек, уже давно не мешает использовать его как полноценный ЯП. Ясное дело, что никто таки не использует за пределами веба – так как там есть свои, более кошерные кандидаты, а вот в вебе – во все поля, и куча ООП-фреймворков на нём.

Deleted
()
Ответ на: комментарий от Deleted

История чем-то напоминает BASIC. Который сначала создавался как язык для новичков (зачем??), потом перенос в VisualBasic – неплохую платформу для формошлёпства с плохеньким языком (хотя, в своё время я видел, как люди на нём игры писали под DirectX). А с приходом .NET стал полноценным ЯП... Как по мне, в нём так и остался уродский синтаксис и многие другие не особо приятные моменты, но по факту по возможностям он не уступает C#, кроме уж совсем специфичных моментов типа unsafe блоков и прямой работы с указателями.

Deleted
()
Ответ на: комментарий от Deleted

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

Deleted
()
Ответ на: комментарий от annulen

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

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

anonymous
()
Ответ на: комментарий от Deleted

Руби если чё развивается очень даже, почитай, что планируется в 3й версии. Экосистема тоже не стоит на месте.

anonymous
()

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

anon8
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.