Как ни странно, две независимых цепочки эволюции могут привести к одинаковому результату.
Вы не можете запретить людям думать.
Ну это уже полемика.
семейство MV*-архитектур, ключевым признаком которых является разделение модели и представления
Текст как раз намекает на то, что в определении классической MV* мало простого отделения модели от представления. Тот факт, что MV* нацелен на то чтобы обновлять представления после их создания и отрисовки при изменении модели, растворяется в объяснении архитектуры и совсем не указывается в определении.
Ну относительно появления настольного MVC, серверное новее.
MVC эволюционировало, став тем, что под этим понимают сейчас
А вот нет. Она является результатом самостоятельной эволюции
Так имеет ли серверное MVC к настольному како-либо отношение или нет? Если Model2 развилось самостоятельно, то зачем ему чужое название?
Просто надо думать
Надо не давать повода так думать.
MVC там как термин практически не употребляется
Чтобы понять MVVM и MVP надо сначала понять MVC, потому что везде при объяснении производных архитектур сначала рассказывают как работает базовая, и потом выделяют отличия.
Нет. я не говорю о том что шаблон надо оставить в покое. И да, популярная на данный момент архитектура серверных приложений вполне может быть результатом эволюции архитектуры настольных приложений.
Но я говорю о том что новому веянию моды нужно новое название, иначе изучив сначала серверное MVC можно продолжить применять этот же вариант архитектуры в настольных приложениях думая, что всё правильно.
Это JS на клиенте, а JS MVC фреймворки могут точно воспроизвести MVC архитектуру, т.к. все части архитектуры находятся в едином адресном пространстве, где издержки на их взаимодействие минимальны.
Фаулер рассматривает шаблоны проектирования применимые к разработке корпоративных информационных систем. При объяснении MVC он рассказывает про то что MVC появился при программировании на Smalltalk и про шаблон Observer. Но дальше просто притягивает за уши.
Фаулер конечно хороший человек, но не пророк. Не стоит принимать все слова на веру, ведь иначе мы будем считать что все открытия уже совершены и дальше развиваться некуда.
Слышал. Согласен. Просто надо повысить процент упоминаний того что MVC это не то о чём кричат на каждом углу. Ведь никто не говорит «PHP Model2 framework», зато все ссылаются на MVС, потому что это знакомое всем слово. Точно так же как и «3D» пытаются присовокупить ко всему чему только можно, даже к зубной пасте, лишь бы лучше продавалась.
1) вы собираетесь каждый клик отправлять на сервер и получать в ответ изменения интерфейса? Не слишком ли накладно?
2) Объясните.
3) Везде пишут что MVC это разделение кода, но акцент на том как его разделять и чем MVC отличается от простой объектной декомпозиции забывают. Клиент и сервер тут очень важны, потому что модель живёт на сервере, а представления, которые генерируют события — на клиенте. Между сервером и клиентом длинный медный провод, который не позволяет нам отправлять все события на сервер.
Видимо надо было добавить сарказма в ту часть где говорится про то что применения ООП достаточно для построения системы. Я как раз считаю что этого недостаточно, и большая часть вашего комментария только подтверждает мои слова.
JS фреймоворки бывают серверные и клиентские. Последние действительно MVC.
Насчёт событий вы правы, но только отчасти. Логически это разные события. Но, если взять php, то при каждом запросе к серверу скрипт запускается заново и заново же создаётся модель. В этом случае нет события изменения объекта представляющего собой модель после того как графический интерфейс уже отображён. Есть вызов программы с параметрами, на основании которых выполняются манипуляции с моделью, а после, производится вставка данных модели в шаблон.
Программы с ГПИ ведут себя иначе. Они запускаются, отрисовывают интерфейс и ожидают события взаимодействия пользователя с элементами управления. При наступлении такого события, изменение модели распространяется на уже отображённые части графического интерфейса.
Даже если на сервере объекты модели будут жить независимо от запросов, сервер не может уведомлять клиенты об изменениях без использования JS (AJAX или WebSocket). Но в таком случае JS реализует MVC на клиентской стороне.
Каким бы ни был летающий автомобиль, пешехода от «наезда» уже не спасёт ни то что он не идёт по проезжей части, ни то что он идёт за ограждением, ни даже то что он находится дома.
Самолёты относительно редко врезаются в здания, но если свой самолёт будет у каждого второго, то жестянщики побратаются с каменщиками.
Node-webkit – мощная штучка, открывающая новые возможности для веб-разработчиков.
Ну да, как С++/Java/PHP программисты тащат в JS свои классы, так и JS программисты пытаются делать всё старым проверенным способом. Но если в первом случае страдает производительность, то во втором — пользователь.
Это в 10 000 раз превышает рекомендации к вероятности побега организмов ГМО, установленных Национальным институтом здоровья США
Притянутое за уши заявление.
Представим что сбежало 10 бактерий, а институт здоровья США одобряет побег 100 бактерий.
Тогда мы бы считали так: 100/10 = 10. Т.е. у нас убежало в 10 раз меньше бактерий чем можно.
Однако сбежало ноль бактерий.
100/0
Кто бы что ни говорил про то что на ноль делить можно, но здесь можно назвать любое число и оно не будет верным.
Сколько лет, сколько зим…
Помню как я ещё пешком под стол ходил, и выспрашивал у тебя про вебмани, когда ты уже вполне работоспособный PaintCAD на waper выкладывал.
Эххх… ностальгия =)
Согласен. Просто стиль написания довольно своеобразный, много слов проглатывается пока Вы летаете в своём воздушном замке. Иллюстрация могла бы многое прояснить.
Очень хорошо, когда у нас есть только разные виды уток. Неплохо, так же, когда кроме уток есть разные виды котиков.
Но становится очень нехорошо, когда у нас есть стреляющая утка и стреляющий котик, а мы располагаем только наследованием.
Вот тут начинается нетривиальное пересечение умений.
В православных языках запрещено множественное наследование, можно только реализовывать множество интерфейсов, но это ведёт к повторению кода.
Выход их этой ситуации — композиция. Именно так получается то, что никак не связанные друг с другом утка и котик умеют одно и то же.
Причём композиция тоже может наследоваться, когда мы собираем её фабрикой, а потом расширяем фабрику так, чтобы она давала эту же композицию и дополнительно несколько новых умений.
Ну это уже полемика.
Текст как раз намекает на то, что в определении классической MV* мало простого отделения модели от представления. Тот факт, что MV* нацелен на то чтобы обновлять представления после их создания и отрисовки при изменении модели, растворяется в объяснении архитектуры и совсем не указывается в определении.
Ну относительно появления настольного MVC, серверное новее.
Так имеет ли серверное MVC к настольному како-либо отношение или нет? Если Model2 развилось самостоятельно, то зачем ему чужое название?
Надо не давать повода так думать.
Чтобы понять MVVM и MVP надо сначала понять MVC, потому что везде при объяснении производных архитектур сначала рассказывают как работает базовая, и потом выделяют отличия.
Но я говорю о том что новому веянию моды нужно новое название, иначе изучив сначала серверное MVC можно продолжить применять этот же вариант архитектуры в настольных приложениях думая, что всё правильно.
Фаулер конечно хороший человек, но не пророк. Не стоит принимать все слова на веру, ведь иначе мы будем считать что все открытия уже совершены и дальше развиваться некуда.
2) Объясните.
3) Везде пишут что MVC это разделение кода, но акцент на том как его разделять и чем MVC отличается от простой объектной декомпозиции забывают. Клиент и сервер тут очень важны, потому что модель живёт на сервере, а представления, которые генерируют события — на клиенте. Между сервером и клиентом длинный медный провод, который не позволяет нам отправлять все события на сервер.
JS фреймоворки бывают серверные и клиентские. Последние действительно MVC.
Насчёт событий вы правы, но только отчасти. Логически это разные события. Но, если взять php, то при каждом запросе к серверу скрипт запускается заново и заново же создаётся модель. В этом случае нет события изменения объекта представляющего собой модель после того как графический интерфейс уже отображён. Есть вызов программы с параметрами, на основании которых выполняются манипуляции с моделью, а после, производится вставка данных модели в шаблон.
Программы с ГПИ ведут себя иначе. Они запускаются, отрисовывают интерфейс и ожидают события взаимодействия пользователя с элементами управления. При наступлении такого события, изменение модели распространяется на уже отображённые части графического интерфейса.
Даже если на сервере объекты модели будут жить независимо от запросов, сервер не может уведомлять клиенты об изменениях без использования JS (AJAX или WebSocket). Но в таком случае JS реализует MVC на клиентской стороне.
Самолёты относительно редко врезаются в здания, но если свой самолёт будет у каждого второго, то жестянщики побратаются с каменщиками.
Ну да, как С++/Java/PHP программисты тащат в JS свои классы, так и JS программисты пытаются делать всё старым проверенным способом. Но если в первом случае страдает производительность, то во втором — пользователь.
Вторая мысль — тьфу, это даже на одну лекцию не тянет.
Притянутое за уши заявление.
Представим что сбежало 10 бактерий, а институт здоровья США одобряет побег 100 бактерий.
Тогда мы бы считали так: 100/10 = 10. Т.е. у нас убежало в 10 раз меньше бактерий чем можно.
Однако сбежало ноль бактерий.
100/0
Кто бы что ни говорил про то что на ноль делить можно, но здесь можно назвать любое число и оно не будет верным.
Помню как я ещё пешком под стол ходил, и выспрашивал у тебя про вебмани, когда ты уже вполне работоспособный PaintCAD на waper выкладывал.
Эххх… ностальгия =)
Но становится очень нехорошо, когда у нас есть стреляющая утка и стреляющий котик, а мы располагаем только наследованием.
Вот тут начинается нетривиальное пересечение умений.
В православных языках запрещено множественное наследование, можно только реализовывать множество интерфейсов, но это ведёт к повторению кода.
Выход их этой ситуации — композиция. Именно так получается то, что никак не связанные друг с другом утка и котик умеют одно и то же.
Причём композиция тоже может наследоваться, когда мы собираем её фабрикой, а потом расширяем фабрику так, чтобы она давала эту же композицию и дополнительно несколько новых умений.