Comments 28
Очень аккуратно оформлено, но к сожаления не правильно. Неправильно с самого начала и до самого конца.
Объяснять конкретно в чем ошибки я не хочу, так как существует миллион намного более правильных статей, на том же Хабре.
Объяснять конкретно в чем ошибки я не хочу, так как существует миллион намного более правильных статей, на том же Хабре.
Правильно, ставьте минуса, ведь чувства автора дороже сознания начинающих разработчиков.
Пусть соотечественники будут намного тупее, чем остальные. Аминь.
Пусть соотечественники будут намного тупее, чем остальные. Аминь.
Думаю, что то что вам «ставят минуса» связано не столько с правильностью статьи, сколько с Вашим комментарием «в духе Ферма»:
Объяснять конкретно в чем ошибки я не хочу, так как ...Вы бы хоть сослались на парочку из этого миллиона статей, право слово.
Скорее всего, минуса летят из-за "… но к сожаления не правильно… Объяснять конкретно в чем ошибки я не хочу" — звучит так же, как у Печкина про посылку.
А Вы считаете что я, как человек, которому не безразличен уровень образования других людей, обязан давать исчерпывающие доказательства неправоты автора, каждой нелепой статьи?
Сказав А надо говорить Б. Это моё мнение и я его ни в коем случае не навязываю.
Люди которые умеют читать между строк, поймут что эту статью не нужно читать обратив внимания на мои коментария. А тем кому суждено стать теми, кто минусует мне и не плюсует тем, кто ниже аргументировал, не поможет уже ничто.
А почему эти люди должны верить вам, а не автору? Вы то своё мнение никак не аргументируете. Ну и вообще, хотелось бы, чтобы программирование перестало быть вопросом веры. У людей читающих статью должна быть своя голова на плечах, чтобы её оценить и аргументированно возразить, если возникнет такая необходимость. Или промолчать, никто не неволит.
Ну если бы Вы не спорили, а читали что я пишу, то также как и те, для кого я оставил первый комментарий, воспользовались поиском, нашли миллион других, более адекватных статей, и все вопросы отпали сами собой.
Точно также люди, которые убедятся в моей правоте, согласятся со мной, что минусымне и плюсы статье поставили хабро-бото-убийцы.
И если эту статью писали не создатели хостинга, то я бы посоветовал им её удалить, чтобы не позорить хостинг. Хотя кто знает, чья это статья.
Точно также люди, которые убедятся в моей правоте, согласятся со мной, что минусымне и плюсы статье поставили хабро-бото-убийцы.
И если эту статью писали не создатели хостинга, то я бы посоветовал им её удалить, чтобы не позорить хостинг. Хотя кто знает, чья это статья.
При чтении статей я привык пользоваться не поиском, а больше собственной головой (чего всем советую). Я против сектантства во всех формах. Если бы Вы потрудились аргументированно объяснить, с чем именно Вы в статье не согласны, уверяю Вас, реакция на Ваши комментарии была бы совсем иной. Но Вам ведь не этого надо?
Да, Вы правы, мне не нужно пользоваться поиском чтобы понять что это ересь.
И мне скрин вообще ни о чем не говорит. Точно так же, как и завышенные мнения людей, которые знают что это фигня, но как мыши проходят мимо, не думая о тех, кому это статью как первую подсунут. И меня не минуса заботят, а плюсы самой статье. И то что те кто минусовал меня не плюсовал тех, кто в отличие от меня стал аргументировать. Все это только компрометирует хабр, который мне нравится больше чем фриковый медиум.
И мне скрин вообще ни о чем не говорит. Точно так же, как и завышенные мнения людей, которые знают что это фигня, но как мыши проходят мимо, не думая о тех, кому это статью как первую подсунут. И меня не минуса заботят, а плюсы самой статье. И то что те кто минусовал меня не плюсовал тех, кто в отличие от меня стал аргументировать. Все это только компрометирует хабр, который мне нравится больше чем фриковый медиум.
Объяснять конкретно в чем ошибки я не хочу" — звучит так же, как у Печкина про посылку
Мне еще больше похоже на
Невероятно, но факт
Очень аккуратно оформлено, но к сожаления не правильно. Неправильно с самого начала и до самого конца.
Объяснять конкретно в чем ошибки я не хочу, так как существует миллион намного более правильных статей, на том же Хабре.
Очень неаккуратный комментарий и, к сожалению, местами неправильный.
Объяснять конкретно в чем ошибки я не хочу, так как существует миллион намного более правильных комментариев, на том же Хабре.
> Контроллер PenguinController занимается обработкой событий и служит посредником между представлением и моделью.
Контроллер не служит посредником. MVC — это модель черного ящика. Есть входы (действия пользователя), есть выходы (это реакция интерфейса), есть внутренняя логика (модель). Входы обрабатывает контроллер, выходы формирует вид. Информация от входов к выходам (от контроллера в вид) пробрасывается моделью. Вся идея MVC — в том, что обработчик входов полностью отделен от обработчика выходов. Если у вас контроллер и вид что-либо знают друг о друге — это нарушает основной принцип MVC. При чем модель в mvc — это не слой взаимодействия с бекендом, это, скорее, аналог view model из mvvm. Слой взаимодействия с бекендом находится за пределами MVC (можно сказать, что к нему должна быть стрелочка от модели). А то, что получилось у вас — это немного кривая mvvm.
Контроллер не служит посредником. MVC — это модель черного ящика. Есть входы (действия пользователя), есть выходы (это реакция интерфейса), есть внутренняя логика (модель). Входы обрабатывает контроллер, выходы формирует вид. Информация от входов к выходам (от контроллера в вид) пробрасывается моделью. Вся идея MVC — в том, что обработчик входов полностью отделен от обработчика выходов. Если у вас контроллер и вид что-либо знают друг о друге — это нарушает основной принцип MVC. При чем модель в mvc — это не слой взаимодействия с бекендом, это, скорее, аналог view model из mvvm. Слой взаимодействия с бекендом находится за пределами MVC (можно сказать, что к нему должна быть стрелочка от модели). А то, что получилось у вас — это немного кривая mvvm.
Входы обрабатывает контроллер
Вообще да, но в случае html ввод ведь поступает от тех же элементов dom, которые рисует представление. Совсем по классике слишком сурово получится — не 70-е ведь.
> Вообще да, но в случае html ввод ведь поступает от тех же элементов dom, которые рисует представление.
Это не существенно, потому что:
1. внутренняя реализация дом-элементов вам не доступна
2. это поведение легко меняется тонкой прослойкой. Например, в реакте все эвенты сперва баблятся до рута и потом оттуда уже распределяются, куда нужно.
> Совсем по классике слишком сурово получится — не 70-е ведь.
Ну естественно, потому и создаются новые варианты архитектуры. В 70-е, чтобы понять, что кто-то кликнул по кнопке — надо было посмотреть, что там по координатам клика, выяснить, что кнопка, проверить, не перекрыта ли она какой-то открытой менюшкой и т.д.
Это и делал (в том числе) контроллер, сейчас контроллеры сверх-тонкие, (click)=«doSomething()» — вот весь ваш контроллер (обычно, но нередко бывают и более сложные кейзы, конечно же), и он сидит в разметке, которая, вроде как, вид. + появилась необходимость отделять стейт приложения (то самое, какой из табов открыт, какой чек нажат и т.д.) от данных — так и появился mvvm (контроллер с видом склеили, за моделью вида разместили модель данных).
Но выдумывать каких-то кадавров с контроллерами-прослойками — не нужно. Представьте себе классический веб — где у вас условный пхп выдает ответы в виде готовой страницы. У вас контроллер на клиенте (очевидно), модель — на беке, но и вид тоже на беке! Как бы вы сделали тут эту химероподобную MVC с контроллером-прослойкой? Отправили данные в модель на беке, оттуда отклик в контроллер на клиенте, который дергает вид с бека? Шиза же. А почему? Потому что поток данных вывернут. По какой такой причине у вас часть приложения, ответственная за обработку реакции пользователя, должна заниматься передачей данных от модели к виду? В этом ведь нету никакой логики.
Это не существенно, потому что:
1. внутренняя реализация дом-элементов вам не доступна
2. это поведение легко меняется тонкой прослойкой. Например, в реакте все эвенты сперва баблятся до рута и потом оттуда уже распределяются, куда нужно.
> Совсем по классике слишком сурово получится — не 70-е ведь.
Ну естественно, потому и создаются новые варианты архитектуры. В 70-е, чтобы понять, что кто-то кликнул по кнопке — надо было посмотреть, что там по координатам клика, выяснить, что кнопка, проверить, не перекрыта ли она какой-то открытой менюшкой и т.д.
Это и делал (в том числе) контроллер, сейчас контроллеры сверх-тонкие, (click)=«doSomething()» — вот весь ваш контроллер (обычно, но нередко бывают и более сложные кейзы, конечно же), и он сидит в разметке, которая, вроде как, вид. + появилась необходимость отделять стейт приложения (то самое, какой из табов открыт, какой чек нажат и т.д.) от данных — так и появился mvvm (контроллер с видом склеили, за моделью вида разместили модель данных).
Но выдумывать каких-то кадавров с контроллерами-прослойками — не нужно. Представьте себе классический веб — где у вас условный пхп выдает ответы в виде готовой страницы. У вас контроллер на клиенте (очевидно), модель — на беке, но и вид тоже на беке! Как бы вы сделали тут эту химероподобную MVC с контроллером-прослойкой? Отправили данные в модель на беке, оттуда отклик в контроллер на клиенте, который дергает вид с бека? Шиза же. А почему? Потому что поток данных вывернут. По какой такой причине у вас часть приложения, ответственная за обработку реакции пользователя, должна заниматься передачей данных от модели к виду? В этом ведь нету никакой логики.
Не соглашусь насчет Вашего определения MVC: это никакой не черный ящик. Черным ящиком могут выступать отдельно Model, View и Controller друг для друга ввиду того, что логика самих компонентов недоступна и может меняться независимо от других, но сами определения каждого из этих компонентов дают понять кто за что отвечает. Controller именно представляет собой связующее звено между Model и View. В идеале из View не должно быть никакого доступа к Model, а все данные он получает от Controller, который и реализует основную логику приложения.
> Черным ящиком могут выступать отдельно Model, View и Controller
Черным ящиком может выступать абсолютно все, что угодно, что данные откуда-то принимает, а потом куда-то передает. И потом описание этого чего-то может быть выражено в форме MVC.
> Controller именно представляет собой связующее звено между Model и View.
Нет, он связывает модель и вид с _устройствами ввода_, то есть входами, И это как раз основная отличающая фишка MVC. Из первой статьи по MVC:
> Controllers contain the interface between their associated models and views and the input devices
(keyboard, pointing device, time).
Ну и сам цикл работы:
> The standard interaction cycle in the Model-View-Controller metaphor, then, is that the user takes
some input action and the active controller notifies the model to change itself accordingly. The
model carries out the prescribed operations, possibly changing its state, and broadcasts to its
dependents (views and controllers) that it has changed, possibly telling them the nature of the
change. Views can then inquire of the model about its new state, and update their display if
necessary. Controllers may change their method of interaction depending on the new state of the
model.
Небольшое пояснение по последнему пункту — у одной модели может быть много пар контроллер+вид, и контроллер отвечает за оркестрацию пар. Например, у каждого меню — свой контроллер (с-но, когда меню открывается, надо деактивировать текущий контроллер, активировать контроллер меню и инициализировать его вид), у какого-нибудь скроллбара тоже свой контроллер — при наведении на скроллбар будет активирован контроллер скроллбара.
> все данные он получает от Controller, который и реализует основную логику приложения.
Это считается одной из самых распространенных ошибок. Контроллер должен быть как можно тоньше, а логика приложения содержится как раз в модели.
Черным ящиком может выступать абсолютно все, что угодно, что данные откуда-то принимает, а потом куда-то передает. И потом описание этого чего-то может быть выражено в форме MVC.
> Controller именно представляет собой связующее звено между Model и View.
Нет, он связывает модель и вид с _устройствами ввода_, то есть входами, И это как раз основная отличающая фишка MVC. Из первой статьи по MVC:
> Controllers contain the interface between their associated models and views and the input devices
(keyboard, pointing device, time).
Ну и сам цикл работы:
> The standard interaction cycle in the Model-View-Controller metaphor, then, is that the user takes
some input action and the active controller notifies the model to change itself accordingly. The
model carries out the prescribed operations, possibly changing its state, and broadcasts to its
dependents (views and controllers) that it has changed, possibly telling them the nature of the
change. Views can then inquire of the model about its new state, and update their display if
necessary. Controllers may change their method of interaction depending on the new state of the
model.
Небольшое пояснение по последнему пункту — у одной модели может быть много пар контроллер+вид, и контроллер отвечает за оркестрацию пар. Например, у каждого меню — свой контроллер (с-но, когда меню открывается, надо деактивировать текущий контроллер, активировать контроллер меню и инициализировать его вид), у какого-нибудь скроллбара тоже свой контроллер — при наведении на скроллбар будет активирован контроллер скроллбара.
> все данные он получает от Controller, который и реализует основную логику приложения.
Это считается одной из самых распространенных ошибок. Контроллер должен быть как можно тоньше, а логика приложения содержится как раз в модели.
UFO just landed and posted this here
> Контроллер это USB коннектор между моделью и видом.
Это не так, я выше уже цитировал:
> Controllers contain the interface between their associated models and views and the input devices
(keyboard, pointing device, time).
Предназначение контроллера — именно изоляции системы от действий пользователя. Это основная его функция в MVC.
> В принципе, он может вообще не обрабатывать никакие события.
Тогда он не нужен, так как не выполняет свою основную функцию.
> Его задача состоит в отделении моделей от видов.
Модель от вида в MVC прослойкой не отделяется (более того — вид вообще по MVC вполне может делать запросы о состоянии модели напрямую). Потому что это приводит к огромным проблемам (см. выше пример), и при этом не приносит никакой пользы. Чтобы разместить прослойку между видом и моделью, необходимо сначала разбить связь между контроллером и моделью. Тогда контроллер естественным образом включается в вид, прослойка называется «Presenter», и вы получаете MVP вместо MVC.
Это не так, я выше уже цитировал:
> Controllers contain the interface between their associated models and views and the input devices
(keyboard, pointing device, time).
Предназначение контроллера — именно изоляции системы от действий пользователя. Это основная его функция в MVC.
> В принципе, он может вообще не обрабатывать никакие события.
Тогда он не нужен, так как не выполняет свою основную функцию.
> Его задача состоит в отделении моделей от видов.
Модель от вида в MVC прослойкой не отделяется (более того — вид вообще по MVC вполне может делать запросы о состоянии модели напрямую). Потому что это приводит к огромным проблемам (см. выше пример), и при этом не приносит никакой пользы. Чтобы разместить прослойку между видом и моделью, необходимо сначала разбить связь между контроллером и моделью. Тогда контроллер естественным образом включается в вид, прослойка называется «Presenter», и вы получаете MVP вместо MVC.
UFO just landed and posted this here
> Да есть MVC с активным видом.
Активный вид или не активный — это совершенно неважно и никак на наличие прослойки не влияет. В описании MVC нету указаний на то, какой там вид. Если вы прочитаете любую из ранних статей по MVC, то вы увидите ровно две вещи:
1. везде контроллер определяется как прослойка между входами и остальной частью системы
2. нигде контроллер не выступает в качестве прослойки между видом и моделью
Если хотя бы одно из условий не выполнено — то у вас не MVC. Совершенно определенно, может быть разница в деталях (активный/пассивный вид, например, к слову, по вашей ссылке схема для пассивного вида неправильная — она от варианта с активным видом должна отличаться только лишь тем, что стрелочка «модель — вид» направлена в другую сторону), но идея паттерна (в случае MVC — отсутствие прослоек между видом и моделью и наличие элемента, который отвечает за обработку входов) — должна сохраняться.
Активный вид или не активный — это совершенно неважно и никак на наличие прослойки не влияет. В описании MVC нету указаний на то, какой там вид. Если вы прочитаете любую из ранних статей по MVC, то вы увидите ровно две вещи:
1. везде контроллер определяется как прослойка между входами и остальной частью системы
2. нигде контроллер не выступает в качестве прослойки между видом и моделью
Если хотя бы одно из условий не выполнено — то у вас не MVC. Совершенно определенно, может быть разница в деталях (активный/пассивный вид, например, к слову, по вашей ссылке схема для пассивного вида неправильная — она от варианта с активным видом должна отличаться только лишь тем, что стрелочка «модель — вид» направлена в другую сторону), но идея паттерна (в случае MVC — отсутствие прослоек между видом и моделью и наличие элемента, который отвечает за обработку входов) — должна сохраняться.
Он пришёл в веб-программирование из настольных приложений и доказал свою эффективность в новой сфере применения.
В этом предложении есть неоднозначность, т.к. веб-программирование — очень широкое понятие. Веб-программированием можно назвать как создание backend, так и создание frontend. При этом MVC для backend действительно проявил себя в новой сфере, если конечно то что используется на стороне сервера можно назвать MVC. Программирование же пользовательского интерфейса на стороне клиента не стало новой сферой применения для архитектурного подхода с названием MVC, т.к. SPA по сути являются теми же desktop приложениями, просто запускаются в runtime в виде браузера.
Модель в этом шаблоне проектирования занята исключительно работой с JSON или объектами, которые поступают с сервера.
А вот это уже антипаттерн. Модель это больше чем просто объектная обёртка к данным. Это ещё и управление состоянием приложения, а оно, отнюдь, не сосредоточено на данных. Например, отображаемая в данный момент вкладка (tab), а точнее информация о том какая вкладка должна быть показана — тоже часть состояния приложения. А концентрация на работе с данными ведёт к тому, что работа с состоянием размазывается по контроллеру.
Контроллер должен играть роль посредника, не заботясь о деталях реализации других компонентов.
О деталях реализации вообще никто заботиться не должен. Но в контексте разделения ответственности между Моделью, Представлением и Контроллером ваше заявление в корне неверно и противоречит вашему же примеру. Как раз наоборот — именно контроллер «знает» за какие ниточки дёргать модель, а за какие представление.
Не видел ещё ни одной статьи про MVC, чтобы в комментариях не было срача про то, что такое тру-MVC. Эта не стала исключением)
А я надеялся увидеть в статье фишки современного js, позволяющие избавиться от необходимости фреймворков.
Я так и не понял какие проблемы использовать mvc в чистом js. Просто разделить комментами 1 файл на 3 части в одной всё обработчики событий это C, в другой всё манипуляции с дом это V, в другой всё остальное это M.
А ООП или функциональное, работа с пространствами имен, это уже другой вопрос.
А ООП или функциональное, работа с пространствами имен, это уже другой вопрос.
Sign up to leave a comment.
MVC на чистом JavaScript