Да, прочитал. И погуглил ещё.
Я раньше думал что эффект испарения достигается за счёт того, что в ЧД падает античастица, которая достигая сингулярности аннигилирует её маленький кусочек эквивалентный своей массе. Ну и естественно думал, что теория неверна, т.к. в ЧД равновероятно падают как античастицы так и частицы и соблюдается баланс.
Сейчас же я понял, что понимая испарение, надо думать лишь о энергии, ибо материя это такое состояние оной. Ну и тут есть два нагугленных варианта. Либо частицы аннигилируют вместе и излучают, а энергию на излучение берут у ЧД, либо одна частица улетает а вторая падает в ЧД и т.к. улетевшая частица добавляет вселенной энергии, то упавшая должна убавить — забрать у ЧД.
Мы с вами ушли в сторону от темы поста. Пост о том, что есть архитектура MVC придуманная для программ с ГПИ и сейчас при разработке веб приложений многие серверную архитектуру называют точно так же. Я не рассматриваю случаи где активно используются ресурсы клиента, для динамического общения клиента с сервером. Только варианты, когда общение с сервером происходит через отправку форм и переходы по ссылкам. В этих случаях весь код приложения исполняется на сервере. И вот архитектура этого кода отличается от архитектуры чисто настольного приложения. Эти две популярные архитектуры имеют очень похожую структуру, но разное поведение, которое обуславливается событиями, которые распространяются по приложению с момента его запуска до момента завершения его работы. А разница в событиях есть, её нам даёт протокол HTTP.
Посмотрите внимательно на пост, в его конце есть опрос, целью которого является выяснение — считают ли люди эти две архитектуры настолько разными, что им нужны разные названия.
Не в обиду вам будет сказано, но основы АОП никто не описывает. Те на кого снизошло озарение, пишут о том какая это хорошая штука, но таких же понятных как по ООП материалов по АОП в открытом доступе нет или настолько мало что они тонут в океане восторженных упоминаний об АОП.
Даже вы пишете про AspectJ — частный случай для одного языка.
Скорее
Server MVC: controller -> model => controller -> view
Где толстая стрелка — это связь по данным, а тонкая — по управлению. Уж что что, а модель контроллер никогда вызывать не должна.
Это кто тут 1000 раз сказал что серверные контроллеры таки отлавливают нажатия клавиш? То MVC я описал в тексте статьи и 999 раз в комментариях сделал акцент на том, что обычно в определении того MVC упоминают только отделение представления от модели, а надо указывать ещё и то, как получившаяся структура реагирует на события. Ведь именно для этого существует диаграмма последовательости. Одной только диаграммы классов мало чтобы показать как ведёт себя тот или иной шаблон.
Поведение MVC в настольном приложении и в серверном (именно HTTP, без динамики) отличаются. Не верите? Постройте диаграммы последовательности для обоих случаев.
Я лишь хочу сказать что разница есть, и возможно, для снижения количества недоразумений при изучении этих похожих архитектур, стоит их по разному называть.
Связь бывает по управлению и по данным. Так что да — они связаны и их надо разделять, но когда они связаны по управлению, сделать это сложнее.
Вы сказали что ваш код никак не связан изменением уже отрисованного представления при изменении модели.
Само по себе разделение приложения на слои ещё не говорит о том что приложение использует MV* архитектуру. Это всего лишь грамотное применение ООП.
MV* же решает проблему отделения представления от модели когда они связаны по управлению, проще говоря — когда надо обновить представление при изменении модели.
Тот факт, что некоторые фреймворки можно без особых усилий перевести на другие принципы общения с клиентом говорит о том что они хорошо спроектированы и Domain у них отделён от Responder'a.
Я же говорю о том, что эта прекрасная архитектура — совсем не то MVC, которое используется в настольных приложениях.
Отличие в том, что в классическом MVC представление с моделью связаны по управлению, в серверной архитектуре представление по управлению связано с контроллером.
В MVC при возникновении события, его ловит контроллер, передаёт модели, а та в свою очередь передаёт на все свои представления.
В серверной архитектуре контроллер так же получает событие, передаёт его модели и после этого передаёт его же представлению.
То о чём я пишу никак не называется, но можно сказать что это не DHTML. Может быть я открою страшную тайну, но http это stateless протокол общения клиента с сервером, где в качестве клиента выступает браузер. Браузер может работать без JS. PHP фреймворки чаще всего ориентированы на генерацию html на сервере.
Протокол HTTP называется stateless не потому что он вообще не сохраняет состояние, а потому что он это состояние не держит постоянно в памяти. Данные в БД, они в БД. Сессия это файл на сервере. Токены форм — они в формах в браузере. Всё это позволяет не обращать внимания на непостоянность пользователя.
Платой за это является то, что сервер не может инициировать передачу данных, он только отвечает.
Чтобы обойти это ограничение есть Long-Polling, WS и постоянно повторяемые AJAX запросы.
Но без JS кода на клиентской стороне это невозможно. А PHP MVC фреймворки по определению реализуют всю MVC архитектуру на сервере. По крайней мере создателям кажется что они реализуют именно MVC.
Но архитектура сервера здесь не играет никакой роли. Можно какую угодно лапшу развести на сервере, система клиент-сервер в целом будет обмениваться событиями.
Я же говорю о том, что архитектура применяемая на серверной стороне и горда именуемая MVC на самом деле таковой не является и называться должна иначе, т.к. решает другую проблему.
1) допустим
2) Long-Polling, HTTP 2.0, WS не являются основой того что называется PHP MVC Framework. Упор там делается на построение Action-Domain-Responder архитекутуры, а живое общение с сервером бывает приплетается для большей динамики.
3) Возможность заменить представление передавая разные объекты классов производных от некоторого класса View ещё не является MVC. MVC решает проблему обновления представления при изменении модели и больше подходит к варианту когда есть много графических представлений, где при работе с одним представлением надо сразу же обновлять все другие. Когда одно представление выводит данные в графический интерфейс, а другое — в файл, тут не требуется распространять изменения моментально, скорее по явному требованию пользователя надо пропустить данные через Responder, который выдаст файл.
Об этом я и говорю. В stateless нет изменения представлений при изменении модели. Модель и представление не связаны по управлению, значит разделить их можно просто помня, что они должны быть отделены.
Вы сами же пришли к тому, что stateless не требуют решения проблемы в виде MV* архитектуры, потому что проблемы нет.
Другое дело Model2 или, предложенный в другом комментарии, Action-Domain-Responder. Эта архитектура уже направляет разработчика в нужном направлении при разделении бизнес-логики и шаблона отображения данных.
Возможно мы мыслим разными категориями. Объясните в чём тут проблема и как она связана с изменением уже отрисованного представления при изменении модели?
MV* решает проблему спагетти бизнеса и представления.
Спасибо что перевели мои же слова на IT жаргон. Видимо матёрые программисты только такими словами и оперируют.
Есть в полный рост
Проблема изменения загруженных страниц при изменении данных в БД решается другим путём. MV* тут ни при чём, разве что клиентский JS MV* фреймворк будет принимать событие с сервера и править страницу, но это уже совсем другая история.
Потому что в stateless возможно лишь одно событие — запуск с параметрами. MV* архитектура решает проблему сильной связности модели и представления при распространения событий изменения модели. В stateless этой проблемы нет, представление один раз забирает данные при создании, и это событие не зависит от того была изменена модель или нет.
Как ни странно, две независимых цепочки эволюции могут привести к одинаковому результату.
Вы не можете запретить людям думать.
Ну это уже полемика.
семейство MV*-архитектур, ключевым признаком которых является разделение модели и представления
Текст как раз намекает на то, что в определении классической MV* мало простого отделения модели от представления. Тот факт, что MV* нацелен на то чтобы обновлять представления после их создания и отрисовки при изменении модели, растворяется в объяснении архитектуры и совсем не указывается в определении.
Я раньше думал что эффект испарения достигается за счёт того, что в ЧД падает античастица, которая достигая сингулярности аннигилирует её маленький кусочек эквивалентный своей массе. Ну и естественно думал, что теория неверна, т.к. в ЧД равновероятно падают как античастицы так и частицы и соблюдается баланс.
Сейчас же я понял, что понимая испарение, надо думать лишь о энергии, ибо материя это такое состояние оной. Ну и тут есть два нагугленных варианта. Либо частицы аннигилируют вместе и излучают, а энергию на излучение берут у ЧД, либо одна частица улетает а вторая падает в ЧД и т.к. улетевшая частица добавляет вселенной энергии, то упавшая должна убавить — забрать у ЧД.
Посмотрите внимательно на пост, в его конце есть опрос, целью которого является выяснение — считают ли люди эти две архитектуры настолько разными, что им нужны разные названия.
Даже вы пишете про AspectJ — частный случай для одного языка.
Server MVC: controller -> model => controller -> view
Где толстая стрелка — это связь по данным, а тонкая — по управлению. Уж что что, а модель контроллер никогда вызывать не должна.
То MVC я описал в тексте статьи и 999 раз в комментариях сделал акцент на том, что обычно в определении того MVC упоминают только отделение представления от модели, а надо указывать ещё и то, как получившаяся структура реагирует на события. Ведь именно для этого существует диаграмма последовательости. Одной только диаграммы классов мало чтобы показать как ведёт себя тот или иной шаблон.
Поведение MVC в настольном приложении и в серверном (именно HTTP, без динамики) отличаются. Не верите? Постройте диаграммы последовательности для обоих случаев.
Я лишь хочу сказать что разница есть, и возможно, для снижения количества недоразумений при изучении этих похожих архитектур, стоит их по разному называть.
Вы сказали что ваш код никак не связан изменением уже отрисованного представления при изменении модели.
Само по себе разделение приложения на слои ещё не говорит о том что приложение использует MV* архитектуру. Это всего лишь грамотное применение ООП.
MV* же решает проблему отделения представления от модели когда они связаны по управлению, проще говоря — когда надо обновить представление при изменении модели.
Я же говорю о том, что эта прекрасная архитектура — совсем не то MVC, которое используется в настольных приложениях.
В MVC при возникновении события, его ловит контроллер, передаёт модели, а та в свою очередь передаёт на все свои представления.
В серверной архитектуре контроллер так же получает событие, передаёт его модели и после этого передаёт его же представлению.
Протокол HTTP называется stateless не потому что он вообще не сохраняет состояние, а потому что он это состояние не держит постоянно в памяти. Данные в БД, они в БД. Сессия это файл на сервере. Токены форм — они в формах в браузере. Всё это позволяет не обращать внимания на непостоянность пользователя.
Платой за это является то, что сервер не может инициировать передачу данных, он только отвечает.
Чтобы обойти это ограничение есть Long-Polling, WS и постоянно повторяемые AJAX запросы.
Но без JS кода на клиентской стороне это невозможно. А PHP MVC фреймворки по определению реализуют всю MVC архитектуру на сервере. По крайней мере создателям кажется что они реализуют именно MVC.
Я же говорю о том, что архитектура применяемая на серверной стороне и горда именуемая MVC на самом деле таковой не является и называться должна иначе, т.к. решает другую проблему.
jigpuzzled написал очень полезный комментарий
2) Long-Polling, HTTP 2.0, WS не являются основой того что называется PHP MVC Framework. Упор там делается на построение Action-Domain-Responder архитекутуры, а живое общение с сервером бывает приплетается для большей динамики.
3) Возможность заменить представление передавая разные объекты классов производных от некоторого класса View ещё не является MVC. MVC решает проблему обновления представления при изменении модели и больше подходит к варианту когда есть много графических представлений, где при работе с одним представлением надо сразу же обновлять все другие. Когда одно представление выводит данные в графический интерфейс, а другое — в файл, тут не требуется распространять изменения моментально, скорее по явному требованию пользователя надо пропустить данные через Responder, который выдаст файл.
Вы сами же пришли к тому, что stateless не требуют решения проблемы в виде MV* архитектуры, потому что проблемы нет.
Другое дело Model2 или, предложенный в другом комментарии, Action-Domain-Responder. Эта архитектура уже направляет разработчика в нужном направлении при разделении бизнес-логики и шаблона отображения данных.
Спасибо что перевели мои же слова на IT жаргон. Видимо матёрые программисты только такими словами и оперируют.
Проблема изменения загруженных страниц при изменении данных в БД решается другим путём. MV* тут ни при чём, разве что клиентский JS MV* фреймворк будет принимать событие с сервера и править страницу, но это уже совсем другая история.
Ну это уже полемика.
Текст как раз намекает на то, что в определении классической MV* мало простого отделения модели от представления. Тот факт, что MV* нацелен на то чтобы обновлять представления после их создания и отрисовки при изменении модели, растворяется в объяснении архитектуры и совсем не указывается в определении.