[Перевод] MVC на чистом JavaScript
Комментарии (8)
21 июля 2017 в 15:34
–6↑
↓
Очень аккуратно оформлено, но к сожаления не правильно. Неправильно с самого начала и до самого конца.
Объяснять конкретно в чем ошибки я не хочу, так как существует миллион намного более правильных статей, на том же Хабре.21 июля 2017 в 15:56 (комментарий был изменён)
–4↑
↓
Правильно, ставьте минуса, ведь чувства автора дороже сознания начинающих разработчиков.
Пусть соотечественники будут намного тупее, чем остальные. Аминь.21 июля 2017 в 16:11 (комментарий был изменён)
+1↑
↓
Думаю, что то что вам «ставят минуса» связано не столько с правильностью статьи, сколько с Вашим комментарием «в духе Ферма»:Объяснять конкретно в чем ошибки я не хочу, так как …
Вы бы хоть сослались на парочку из этого миллиона статей, право слово.21 июля 2017 в 16:33
0↑
↓
Скорее всего, минуса летят из-за »…, но к сожаления не правильно… Объяснять конкретно в чем ошибки я не хочу» — звучит так же, как у Печкина про посылку.
21 июля 2017 в 16:34
0↑
↓
> Контроллер PenguinController занимается обработкой событий и служит посредником между представлением и моделью.Контроллер не служит посредником. MVC — это модель черного ящика. Есть входы (действия пользователя), есть выходы (это реакция интерфейса), есть внутренняя логика (модель). Входы обрабатывает контроллер, выходы формирует вид. Информация от входов к выходам (от контроллера в вид) пробрасывается моделью. Вся идея MVC — в том, что обработчик входов полностью отделен от обработчика выходов. Если у вас контроллер и вид что-либо знают друг о друге — это нарушает основной принцип MVC. При чем модель в mvc — это не слой взаимодействия с бекендом, это, скорее, аналог view model из mvvm. Слой взаимодействия с бекендом находится за пределами MVC (можно сказать, что к нему должна быть стрелочка от модели). А то, что получилось у вас — это немного кривая mvvm.
21 июля 2017 в 16:56
0↑
↓
Входы обрабатывает контроллер
Вообще да, но в случае html ввод ведь поступает от тех же элементов dom, которые рисует представление. Совсем по классике слишком сурово получится — не 70-е ведь.
21 июля 2017 в 16:45
+1↑
↓
Он пришёл в веб-программирование из настольных приложений и доказал свою эффективность в новой сфере применения.
В этом предложении есть неоднозначность, т.к. веб-программирование — очень широкое понятие. Веб-программированием можно назвать как создание backend, так и создание frontend. При этом MVC для backend действительно проявил себя в новой сфере, если конечно то что используется на стороне сервера можно назвать MVC. Программирование же пользовательского интерфейса на стороне клиента не стало новой сферой применения для архитектурного подхода с названием MVC, т.к. SPA по сути являются теми же desktop приложениями, просто запускаются в runtime в виде браузера.Модель в этом шаблоне проектирования занята исключительно работой с JSON или объектами, которые поступают с сервера.
А вот это уже антипаттерн. Модель это больше чем просто объектная обёртка к данным. Это ещё и управление состоянием приложения, а оно, отнюдь, не сосредоточено на данных. Например, отображаемая в данный момент вкладка (tab), а точнее информация о том какая вкладка должна быть показана — тоже часть состояния приложения. А концентрация на работе с данными ведёт к тому, что работа с состоянием размазывается по контроллеру.Контроллер должен играть роль посредника, не заботясь о деталях реализации других компонентов.
О деталях реализации вообще никто заботиться не должен. Но в контексте разделения ответственности между Моделью, Представлением и Контроллером ваше заявление в корне неверно и противоречит вашему же примеру. Как раз наоборот — именно контроллер «знает» за какие ниточки дёргать модель, а за какие представление.21 июля 2017 в 16:54
+1↑
↓
Не видел ещё ни одной статьи про MVC, чтобы в комментариях не было срача про то, что такое тру-MVC. Эта не стала исключением)