Различия между MVVM и остальными MV*-паттернами

[RouR]

Можете привести пример использования MVVM в Web? Не Silverlight.

[dmdev]

К сожалению я не могу привести пример для Web. Я занимаюсь разработкой мобильных приложений под Android. Может кто-то из читателей приведет примеры.

[dmdev]

Возможно стоит погуглить на тему Sencha Ext JS 5

[Simplevolk]

А для Android есть MVVM? Насколько я знаю, автосвязывания там нет.

[terrakok]

Я думаю, самый подробный ответ на ваш вопрос в статье Как перестать использовать MVVM

[dmdev]

Нормального MVVM нет, но гугл пилит databinding

[aquamakc]

Xamarin по идее должен поддерживать. XAML есть, было бы странно отказываться от Binding`а.

[dmdev]

Xamarin не нативное решение

[aquamakc]

А кто-то говорил про нативные средства?

[dmdev]

Я бы сначала присмотрелся к нативным решениям и библиотекам

[Dampir]

Для Xamarin есть шикарный MugenMvvmToolkit.

Статья о нем на Хабре.

[Arvalon]

Какую шаблон (MVP, MVC или др.) на Android предпочитаете и пользуетесь ли каким-нибудь framework'ом (Moxy, Mosby)?

[dmdev]

Мне нравится MVP. Очень хорошо себя зарекомендовала Moxy. Ничего лишнего, простая в использовании библиотека, избавляет от написания рутинного кода. Ты применяешь MVP на практике и не беспокоишься о том, как реализовать этот паттерн. Киллер-фича Moxy — это восстановление состояния. Советую!

На самом деле, в андроиде уже есть свой MVP: если из фрагмента вынести весь UI-код в кастомные View, то он по сути станет презентером. Только связь со View будет жесткая, а не через интерфейс. У такого подхода на фрагментах есть проблемы:

• Фрагменты сложно тестировать, так как они тянут много android-зависимостей и самостоятельно создают View
• У фрагментов сложный жизненный цикл и они умирают вместе с Activity. При поворотах можно воспользоваться setRetainInstance(true), но это не работает на child-фрагментах.
• Нужно писать много рутинного кода для восстановления View
• Жесткая связь со View

Про MVVM ничего не могу сказать, но писать связывание данных в xml меня напрягает. Если интересно, то мой коллега написал хорошую статью про проблемы с ним в андроиде.

Есть еще интересный паттерн Presentation Model, о котором мало кто знает и мало кто говорит. В нем нет тех проблем, что есть в MVVM, но приходится писать код связывания самостоятельно, практически для каждого свойства. Я планирую написать несколько статей о том, как его можно реализовать на андроиде.

[Arvalon]

Moxy не сложен в освоении? Статья от разработчика даёт теоретические представления а пример приложения уже наоборот, перегружен. Если Moxy у вас рабочий повседневный инструмент может быть напишите статью о его реализации?

[dmdev]

Загляните в wiki, там все достаточно просто. Только про стратегии сохранения стейта почитайте отдельно.

[senneco]

Сейчас я готовлюсь к DevFest Nsk, на котором кроме доклада будет ещё и codelab. Для этого я готовлю много простых и понятных примеров. После DevFest (а может и раньше) эти примеры появятся в wiki ;)

[Fedcomp]

Knockoutjs вроде

[inoyakaigor]

Angular его использует, а также любой другой JS фреймворк с двусторонним связыванием данных.

[f_s_b_37]

Уточнеение: ангуляр это MVW (Model — Veiw — Whatever). То есть кроме MVVM на нем можно использовать и другие MV* паттерны. А вот knockout да — вполне себе характерная реализация MVVM.

[radtie]

Мне кажется, что ангуляр просто боится сам себе признаться, что он MVVM ;)

[Noobkesan]

Vue.js

[A1ien]

В asp.net mvc очень часто как результат метода контроллера и модели для View используется не непосредственно елемент доменной модели, а некая промежуточная сущность которая называеться View Model, для того чтобы не тащить специфичные для view атрибуты в доменную модель, да и часто доменная модель не соответсвует один в один View и требует некой конверсии. Например в доменной модели цвет хранится как int32, а во View используется некий класс Color для преставления в элементах выбора цвета. Именно в связи с этим часто используют чтото вроде automaper. Это конечно не классический пример MVVM но все же близко. Тут controller присутствует, но его обязанности можно свести к минимуму, и всю логику инкапсулировать в ViewModel.

[Jeevuz]

В одном подкасте один разработчик рассказывал, что в MVVM когда используется несколько ViewModel, зависящих друг от друга, то используется controller над ними.

К примеру, строка поиска со своей VM, а карточка с результатом со своей. И вот мы нажали поиск в строке поиска и нам надо отобразить прогресс в карточке. Передача этого действия будет через их общий controller.

Есть, конечно, разные пути сделать то же самое. Но я вспомнил это, прочитав ваш пример. Получается, что и в правду, описанный вами подход составляет MVVM в одном из видов реализации связи между VM. В подкасте речь была вроде про WPF.

[dmdev]

Если речь идет о передаче данных между компонентами, то я бы назвал это шиной данных.

[Jeevuz]

Шина данных не несет логики, а этот controller может содержать свою логику. А может вообще быть родительской VM. Так что речь не о шине данных.

[pawlo16]

Самый известный пример — Meteor.js

[Jeevuz]

В контексте этой статьи хочется привлечь внимание к тому, как часто люди называют свои реализации паттернов не теми именами. Это, конечно, не страшно, но создает путанницу.

Так, к примеру, сейчас очень часто можно встретить описание решений типа "какой-то там MVVM". Начинаешь читать и понимаешь, что в этом решении не автоматический датабиндинг, а создается какой-то свой вид биндинга. Но, MVVM - automatic databinding = PresentationModel, а люди упорно называют это MVVM.

Я надеюсь, что прочитав эту статью вы увидите разницу между этими паттернами и присоединитесь ко мне в том, чтобы называть вещи правильными именами. Хотя бы как дань уважения создателям этих паттернов.

[arthurlomakin]

Использую MVVM в WPF приложениях с INotifyPropertyChanged.

В 1979 году! (Я тогда ещё даже не родился).

Я родился в 2005-ом