MVC vs MVVM за чем будущее?

Question

[Limbo]

По вашему мнению, что наиболее популярно на данный момент шаблонах проектирования MVC и MVVM , и за чем будущее ?

Какие можете привести примеры по MVVM ? Я знаю только Silverlight

Answer 1

[Сергей Протько]

Будущее за теми, кто хотя бы умеет читать википедию.

Для справки, ни MVVM ни MVC не являются шаблонами проектирования. Это схема использования нескольких шаблонов проектирования. Основная идея оных - разделение логики на слои. MVC декларирует разделение на логику представления, бизнес логику и связывающие это все контроллеры. В MVVM же основная идея заключается в более удобном управлении представлением модели. Особенно в случае когда модель может меняться из слоя представления (из UI тобиш, датабиндинги и все такое).

p.s. Помимо MVC и MVVM существует масса других схожих схем, типа MVP, HMVC, PAC...

Answer 2

[xmoonlight]

MVC vs MVVM

и за чем будущее ?

вот и я говорю: Зачем?!))

Делать нужно не по PR-"технологиям", а по структурным связям объектов при их взаимодействии в том или ином случае. А они - разные бывают.

Answer 3

[vasIvas]

Прежде чем получить ответ, Вам нужно понять,
что у всех людей mvc разное, точнее, разная реализация.

Возьму для примера логику 90% и Сергей Протько в том числе.

MVC декларирует разделение на логику представления, бизнес логику и связывающие это все контроллеры.

Следом идем в Model-View-Controller и читаем -

Наиболее типичная реализация отделяет вид от модели путем установления между ними протокола взаимодействия, используя аппарат событий (подписка/оповещение). При каждом изменении внутренних данных в модели она оповещает все зависящие от неё представления, и представление обновляется. Для этого используется шаблон «наблюдатель». При обработке реакции пользователя вид выбирает, в зависимости от нужной реакции, нужный контроллер, который обеспечит ту или иную связь с моделью. Для этого используется шаблон «стратегия», или вместо этого может быть модификация с использованием шаблона «команда». А для возможности однотипного обращения с подобъектами сложно-составного иерархического вида может использоваться шаблон «компоновщик». Кроме того, могут использоваться и другие шаблоны проектирования, например, «фабричный метод», который позволит задать по умолчанию тип контроллера для соответствующего вида.

Тут ясным языком сказано, что модель посылает события, а представление их ловит и изменяется. Можно было бы предположить, что контроллер является "наблюдателем", но нет. Контроллер, это отдельная структура данных, которая
в большинстве случаев заключает в себе некую, контрольскую логику, которая
убивает мысль о контроллере "наблюдателе", так как один объект не может делать больше одной обязанности.
Конечно можно эти слова натянуть к любой реализации, но чтобы до конца разобраться нужно открыть книгу GoF в которой написано -


Можно и это трактовать по разному, но дальше идет картинка и чугунно-бетонная точка -


Ну а так же картинку с вики -


Буду раз выслушать другие взгляды, но только с приведением ссылок на авторитетные источники, а не статьи смертных и тем более неправильные реализации framwork'ов.

Comments

[vsuhachev]

Насколько я могу судить - Сергей Портько не сказал ничего что противоречит вашему посту, за который вам спасибо огромное!

[vasIvas]

vsuhachev: Сергей Портько сказал -

MVC декларирует разделение на логику представления, бизнес логику и связывающие это все контроллеры.

Что означает - бизнес логика ( что является логикой приложения ) отделить от логики представления и для связи их создать контроллер.
Это в свою очередь означает, что когда виду нужно будет получить данные из модели, он попросит контроллер взять их у модели и передать ему. Если модели нужно что-то приказать представлению, то он просит контроллер передать приказ виду.

Но в предложении после картинки из книги GoF явно говорится, что модель оповещает нужные ей представления ( посылает события ) после чего представления берут данные из модели ( это означает, что у представления есть ссылка на модель ). Для связи в классическом mvc контроллер не нужен. В книге он вообще упомянут лишь в вскользь.
Но тут многие скажут, что вид имеющий ссылку на модель нарушает принцип... Нет! Вид не работает с моделью и ссылку на него не имеет, он работает с абстракцией модели.

[vsuhachev]

vasIvas: Насколько я понял, основная мысль и там и у вас - реализации MVC могут быть разные. К этому плюсуюсь :)

[vasIvas]

vsuhachev: еслиЯбудуПисатьТакВыЖеВсеРавноПоймете?АОзначаетЛИЭтоЧтоТакМожноПисать?

[vsuhachev]

КаждыйПишетКакхочет, концепция MVC пошла в массы и получила реализации немного другие чем ваш "паттерн" из GoF и смолтока. Вот dhh в рельсах так реализовал его, а не через подписку на события потому что так было оптимальней для веба. Что в этом плохого?

[vsuhachev]

Вот вы пишите "Вид не работает с моделью и ссылку на него не имеет, он работает с абстракцией модели."

Кто то эту абстракцию разместил в контроллере. А дальше получаем "MVC декларирует разделение на логику представления, бизнес логику и связывающие это все контроллеры".

[vasIvas]

После того, как поместили абстракцию в контроллере, следом придумали название для такой реализации - жирный и уродливый контроллер. Об этом на вики написано. И не важно в рельсах это или нет, законы ооп и mvc везде одинаковые. И усовершенствование, это когда на Вас доспехи одевают, а не выдергивают руки и прикрепляют на спину.

[Сергей Протько]

vasIvas: тут важно понимать еще контекст задачи. Скажем в backend разработке модель крайне редко должна нотифаить вью о том что она поменялась так как все изменения происходят в рамках запроса. Именно по этому на сервере никогда почти не применяют чистый MVC хотя и называют это MVC.

В дескптопных приложениях все чуть веселее. Там да, вью может обновлять себя в ответ на изменение модели по событиям. В этом случае MVC себя показывает не очень так как модель должна помимо бизнес логики еще и уведомлять всех и вся, увеличивается связанность и т.д. С другой стороны контроллер выполняет крайне мало обязанностей, по сути его задача в контексте UI приложения обрабатывать ввод пользователя и передавать в модель, связывать модель и представление (я имею ввиду говорить какое представление для модели использовать в данный момент). Потому и были добавлены схемы типа MVP/MVVM которые вносят еще один слой чья задача как раз таки связывание данных между моделью и представлением, нотификация вью об изменениях модели и т.д.

[vasIvas]

Сергей Протько: если рассматривать на примере игр, то модель === игра. То есть, нужно проектировать модель так, чтобы в нее можно было играть без представления.
От сюда и появилось утверждение, что представление должно обновляться по событиям модели.
Если реакция пользователя не затрагивает модель, то представление разруливает все без контроллера. То есть, контроллер не всегда реагирует на событие клавиатуры и мыши.
Контроллер служит лишь для связи модели и представления.

Связанности никакой нет. Связанность это когда я передал в модель ссылку на представление и вызываю его "специфический" метод, предположим, myViewUpdate.
Теперь, если мне нужно будет поменять представление, то моя модель будет диктовать ему правила, навязывая метод myViewUpdate. А при событиях модели не нужно ничего знать об окружающем мире, она работает и шлет события, а вот кто их поймает, её не волнует. Сегодня это одно представление, завтра другое. Связанности нет.