Можно я буду использовать номера вместо цитирования? Надоели огромные комментарии и то, что разговор стоит на месте.
Автоматическое связывание в вашем понимании означает, что нет бойлерплейта? Все верно? Если да, то у меня для вас новость. В андроиде нужно либо оборачивать каждое поле в ObservableField<T>, либо сам класс модели должен наследовать интерфейс Observable, а в сеттерах должен вызываться метод, уведомляющий об изменениях. Аналогично и в WPF, вы используете либо DependencyProperty на каждое свойство, либо интерфейс INotifyPropertyChanged (и его родственников), превращая авто-свойства из одной строки в простыни однотипного текста. Всё перечисленное — boilerplate.
Уже одно это разбивает вашу предпосылку (та, что в цитате 1) в щепки.
Далее про "автоматическое Шрёдингера".
Вы называете автоматическим связыванием отсутствие boilerplate кода.
Автоматическое, значит без участия человека, совсем [1]. В отличии от автоматизированного, где требуется участие человека. Поэтому я и утверждаю, что его нет. Ведь во всех MVVM-фреймворках приходится писать что с чем связать, даже если мало. А как мы только что выяснили, еще и boilerplate нужен, так что его дважды нет.
А что происходит автоматически, так это изменение одних значений сразу после изменений других [2].
Так вот, [1] и [2] — это две разные вещи. Я догадывался по прошлым коментариям, что вы их не различаете, но теперь точно знаю.
Теперь про знакомые слова. Вы не видите смысла за отдельными словами. ".NET's data binding" — название конкретной технологии, а не databinding как самостоятельное понятие. "The data binding engine in Avalon" — оно же применительно конкретно к Avalon (WPF), т.е. еще более узко.
Здесь написано вовсе не "data binding делает работу автоматической". Здесь написано "вот это конкретная реализация от Microsoft автоматизирует всю работу". А вы почему-то решили из отдельных слов составить тот смысл, который вам будет удобен.
Обратите внимание еще и вот на что:
Автоматизирует. Здесь говорится именно об этом. Автоматизированный это не автоматический.
Прочтите выше про boilerplate в моделях, и поймете, что они погорячились насчет "all"
Ведь, код, необходимый для связывания появится автоматически
Неверно, не весь, см. про boilerplate.
Про краткость (в XML) не стану отрицать. Но где граница между "достаточно кратко" и "еще слишком многословно"? Кто должен это решать, и почему он? То, что эта граница субъективна по своей природе — еще одна причина, по которой "краткость записи" не может служить критерием для разделения между PM и MVVM.
Может, вообще не стоит различать PM и MVVM, а считать их разными именами одной сущности. Некоторые авторы так и делают. (То, что я пишу это, не значит, что ваши ошибки, на которые я указал выше, исчезли. Если вы над ними подумаете, это не сделает вас глупее или проигравшим).
В таком случае называть эту архитектуру MVVM также некорректно, как и говорить, что это PM.
Если вас устроит такой вывод, предлагаю завершить разговор. (Продолжить можно, но я устал от него)
Комментарий снова получился гигантским. Если я где-то в нем задел вас, прошу прощения, это неумышленно.
Предыдущий комментарий был о том, что такое связывание. Отвечая, я исходил из того, что вы прочли первый комментарий, на который отвечали:
Может, data binding сам должен обновлять View? Связывание само не происходит, в том или ином виде оно всегда описано. Содержание остается тем же, а несущественная разница в форме не делает его "ручным" или "автоматическим".
То есть даже если за вас методы, инициирующие связывание, вызывает парсер разметки, вы все равно обязаны указать ему, что с чем связывать. Не укажете ничего — ничего и не свяжется "само".
Другими словами, я утверждаю, что связывание автоматически не происходит нигде. Автоматически изменяются значения зависимых свойств благодаря связыванию.
И это не просто мое мнение. Что Фаулер, что Microsoft в своих материалах применяют слово автоматический в ином контексте: при изменении некого значения другое должно автоматически меняться вслед за ним. И все, вот так банально. А data binding — это механизм, благодаря которому такое автоматическое изменение происходит. А те реализации, которые предоставляют android/winforms/wpf/angular/whatever, просто делают его кратким/удобным для использования (а иногда наоборот).
Причем, если смотреть на то, как красиво оно описано/количество boilerplate-кода, то с этим в настоящей статье все хорошо. Человек, знакомый с Rx, с легкостью опознает в строке
Оповещает, конечно. Просто он некрасив. Обратимся к Фаулеру, который, как вы думаете, на вашей стороне, за определением:
Data Binding
A mechanism that ensures that any change made to the data in a UI control is automatically carried over to the underlying session state (and vice versa).
Как видите, здесь лишь общие слова, и нигде не сказано, какую форму должен принимать data binding — {Binding ...}, source.subscribe(target) или же уродливый классический listener.
Зато в определении сказано, что смысл Data Binding в том, что изменения сразу передаются из UI в состояние и наоборот. То есть изменяются синхронно, а состояние двух частей приложения, соответственно, синхронизировано, в чем и заключается основной профит привязывания данных.
Таким образом, даже простой listener, который занимается синхронизацией двух значений, формально полностью подходит под это определение. Да даже без Фаулера сложно спорить с тем, что если вы заставили синхронно изменяться данные, то вы их связали.
И кстати, из этого определения также следует, что автор статьи ошибочно противопоставляет binding при помощи Rx (частную реализацию) data binding'у в целом (общему понятию).
Data Binding, помимо названия отдельных технологий, еще и абстракция. И в данной статье она применена.
Я как раз никого не путаю, а напротив, пытаюсь развеять заблуждения.
Статьи я прочел (почему вы решили иначе?).
И позже, в WPF его добавили (позже).
Неверно, data binding в WPF присутствовал с момента первого релиза (WPF 3.0).
Поэтому называть PM как MVVM это как называть мотоцикл автомобилем.
Согласен. Но называть автомобиль мотоциклом я также не буду.
Суть отличия не просто в наличии databinding'а. Он есть и там и там. Data binding в прямую переводится как связывание данных. Без этого все паттерны были бы бесполезны.
Отличие — в наличии автоматического датабиндинга.
Того, на чем вы так сильно ставите акцент, нет ни по одной ссылке. Что для вас автоматическое, а что нет?
Думаю, вы не там ищете разницу.
Было бы очевидно, что все делается вручную, если бы все ивенты по старинке обрабатывались вручную, и в каждом обработчике в императивном стиле изменялись бы зависимые свойства View или PM. Такое никак нельзя было бы назвать MVVM.
Здесь же, благодаря Rx, присутствует "автоматическое" оповещение об изменениях свойств, и все связи описаны декларативно в том самом onBindPresentationModel подобно тому, как это делается в разметке в других реализациях.
Приведу цитату из статьи по второй ссылке. Совсем короткая, но в ней собрано всё, чтобы понять суть:
If the binding has the correct settings and the data provides the proper notifications, then, when the data changes its value, the elements that are bound to the data reflect changes automatically.
Все это присутствует у автора:
data provides the proper notifications = Observable типы в PM
if the binding has the correct settings = onBindPresentationModel написан без ошибок
when the data changes its value, the elements that are bound to the data reflect changes automatically = после "активации" связей путем однократного выполнения onBindPresentationModel элементы View автоматически меняются вслед за изменением VMPM, и наоборот (например, для полей ввода)
Не совсем. Если почитать о MVVM, то становится ясно, что data binding — это один из столпов MVVM. А согласно описанию data binding, он должен сам связывать вьюшку с вьюмоделью, в то время как с Rx это приходится делать самому.
Может, data binding сам должен обновлять View? Связывание само не происходит, в том или ином виде оно всегда описано. Содержание остается тем же, а несущественная разница в форме не делает его "ручным" или "автоматическим".
Так что автор все правильно написал. Ведь, грубо говоря, если из MVVM убрать data binding, то получим PresentationModel.
Верно, и автор как раз добавил data binding в форме Rx.
Вручную или автоматически, это субъективно. В том же WPF и прочих XAML само ничего не происходит, во View обязательно должно быть указано, к каким частям ViewModel она привязана, иначе это уже какая-то магия. В вашей реализации связывание происходит в onBindPresentationModel. Возможно, оно выглядит непривычно, т.к. описано не внутри разметки. Но где ему быть, это детали конкретной реализации, а суть в точности та же.
Если совсем абстрагироваться от деталей и посмотреть еще раз, то в понимании MVVM Fragment — это слой View, и в нем таким же образом, как в XAML или XML (на примере Android Data Binding Library) описаны привязки. Я вижу MVVM.
Насколько я понял, это все-таки просто MVVM, в котором ViewModel называется PresentationModel, а в качестве механизма связывания данных используется Rx.
А почему нет? Важно, что на CPU как не изворачивайся, быстрее не получится. На GPU же возможность имеется, а будет ли она реализована — уже другой вопрос.
«От некоторых ребят были запросы в духе “А расскажите про реактивное программирование на Java и на Swift”. Это сейчас модно, но мы решили ничего не рассказывать про React.»
… потому что не знаем, что React не про реактивное программирование?
Польза в любом случае будет, как для других, так и для вашего проекта. Могут появиться форки (что хорошо), а ваш проект сможет получать улучшения не только от вас. Это могут быть и багфиксы, и поддержка новых железок, и даже просто рефакторинг. По-моему, в выигрыше от этого будут все.
Можно я буду использовать номера вместо цитирования? Надоели огромные комментарии и то, что разговор стоит на месте.
Автоматическое связывание в вашем понимании означает, что нет бойлерплейта? Все верно? Если да, то у меня для вас новость. В андроиде нужно либо оборачивать каждое поле в
ObservableField<T>, либо сам класс модели должен наследовать интерфейсObservable, а в сеттерах должен вызываться метод, уведомляющий об изменениях. Аналогично и в WPF, вы используете либоDependencyPropertyна каждое свойство, либо интерфейсINotifyPropertyChanged(и его родственников), превращая авто-свойства из одной строки в простыни однотипного текста. Всё перечисленное — boilerplate.Уже одно это разбивает вашу предпосылку (та, что в цитате 1) в щепки.
Далее про "автоматическое Шрёдингера".
Вы называете автоматическим связыванием отсутствие boilerplate кода.
Автоматическое, значит без участия человека, совсем [1]. В отличии от автоматизированного, где требуется участие человека. Поэтому я и утверждаю, что его нет. Ведь во всех MVVM-фреймворках приходится писать что с чем связать, даже если мало. А как мы только что выяснили, еще и boilerplate нужен, так что его дважды нет.
А что происходит автоматически, так это изменение одних значений сразу после изменений других [2].
Так вот, [1] и [2] — это две разные вещи. Я догадывался по прошлым коментариям, что вы их не различаете, но теперь точно знаю.
Теперь про знакомые слова. Вы не видите смысла за отдельными словами. ".NET's data binding" — название конкретной технологии, а не databinding как самостоятельное понятие. "The data binding engine in Avalon" — оно же применительно конкретно к Avalon (WPF), т.е. еще более узко.
Здесь написано вовсе не "data binding делает работу автоматической". Здесь написано "вот это конкретная реализация от Microsoft автоматизирует всю работу". А вы почему-то решили из отдельных слов составить тот смысл, который вам будет удобен.
Обратите внимание еще и вот на что:
Неверно, не весь, см. про boilerplate.
Про краткость (в XML) не стану отрицать. Но где граница между "достаточно кратко" и "еще слишком многословно"? Кто должен это решать, и почему он? То, что эта граница субъективна по своей природе — еще одна причина, по которой "краткость записи" не может служить критерием для разделения между PM и MVVM.
Может, вообще не стоит различать PM и MVVM, а считать их разными именами одной сущности. Некоторые авторы так и делают. (То, что я пишу это, не значит, что ваши ошибки, на которые я указал выше, исчезли. Если вы над ними подумаете, это не сделает вас глупее или проигравшим).
В таком случае называть эту архитектуру MVVM также некорректно, как и говорить, что это PM.
Если вас устроит такой вывод, предлагаю завершить разговор. (Продолжить можно, но я устал от него)
Комментарий снова получился гигантским. Если я где-то в нем задел вас, прошу прощения, это неумышленно.
Предыдущий комментарий был о том, что такое связывание. Отвечая, я исходил из того, что вы прочли первый комментарий, на который отвечали:
То есть даже если за вас методы, инициирующие связывание, вызывает парсер разметки, вы все равно обязаны указать ему, что с чем связывать. Не укажете ничего — ничего и не свяжется "само".
Другими словами, я утверждаю, что связывание автоматически не происходит нигде. Автоматически изменяются значения зависимых свойств благодаря связыванию.
И это не просто мое мнение. Что Фаулер, что Microsoft в своих материалах применяют слово автоматический в ином контексте: при изменении некого значения другое должно автоматически меняться вслед за ним. И все, вот так банально. А data binding — это механизм, благодаря которому такое автоматическое изменение происходит. А те реализации, которые предоставляют android/winforms/wpf/angular/whatever, просто делают его кратким/удобным для использования (а иногда наоборот).
Причем, если смотреть на то, как красиво оно описано/количество boilerplate-кода, то с этим в настоящей статье все хорошо. Человек, знакомый с Rx, с легкостью опознает в строке
привязку одного свойства к другому. Вам нужно еще более "автоматически"?
А вот вы на мой вопрос "Что для вас автоматическое, а что нет?" не ответили.
Либо я плохо смотрю. Хотя несколько раз просмотрел ваши комментарии, но ответа не увидел. Не могли бы вы написать еще раз?
Попытка съязвить не усилит вашу аргументацию.
Оповещает, конечно. Просто он некрасив.
Обратимся к Фаулеру, который, как вы думаете, на вашей стороне, за определением:
Как видите, здесь лишь общие слова, и нигде не сказано, какую форму должен принимать data binding —
{Binding ...},source.subscribe(target)или же уродливый классический listener.Зато в определении сказано, что смысл Data Binding в том, что изменения сразу передаются из UI в состояние и наоборот. То есть изменяются синхронно, а состояние двух частей приложения, соответственно, синхронизировано, в чем и заключается основной профит привязывания данных.
Таким образом, даже простой listener, который занимается синхронизацией двух значений, формально полностью подходит под это определение. Да даже без Фаулера сложно спорить с тем, что если вы заставили синхронно изменяться данные, то вы их связали.
И кстати, из этого определения также следует, что автор статьи ошибочно противопоставляет binding при помощи Rx (частную реализацию) data binding'у в целом (общему понятию).
Data Binding, помимо названия отдельных технологий, еще и абстракция. И в данной статье она применена.
Я как раз никого не путаю, а напротив, пытаюсь развеять заблуждения.
Статьи я прочел (почему вы решили иначе?).
Неверно, data binding в WPF присутствовал с момента первого релиза (WPF 3.0).
Согласен. Но называть автомобиль мотоциклом я также не буду.
Того, на чем вы так сильно ставите акцент, нет ни по одной ссылке. Что для вас автоматическое, а что нет?
Думаю, вы не там ищете разницу.
Было бы очевидно, что все делается вручную, если бы все ивенты по старинке обрабатывались вручную, и в каждом обработчике в императивном стиле изменялись бы зависимые свойства View или PM. Такое никак нельзя было бы назвать MVVM.
Здесь же, благодаря Rx, присутствует "автоматическое" оповещение об изменениях свойств, и все связи описаны декларативно в том самом
onBindPresentationModelподобно тому, как это делается в разметке в других реализациях.Приведу цитату из статьи по второй ссылке. Совсем короткая, но в ней собрано всё, чтобы понять суть:
Все это присутствует у автора:
Observableтипы в PMonBindPresentationModelнаписан без ошибокonBindPresentationModelэлементы View автоматически меняются вслед за изменениемVMPM, и наоборот (например, для полей ввода)Может, data binding сам должен обновлять View? Связывание само не происходит, в том или ином виде оно всегда описано. Содержание остается тем же, а несущественная разница в форме не делает его "ручным" или "автоматическим".
Верно, и автор как раз добавил data binding в форме Rx.
Вручную или автоматически, это субъективно. В том же WPF и прочих XAML само ничего не происходит, во View обязательно должно быть указано, к каким частям ViewModel она привязана, иначе это уже какая-то магия. В вашей реализации связывание происходит в
onBindPresentationModel. Возможно, оно выглядит непривычно, т.к. описано не внутри разметки. Но где ему быть, это детали конкретной реализации, а суть в точности та же.Если совсем абстрагироваться от деталей и посмотреть еще раз, то в понимании MVVM
Fragment— это слой View, и в нем таким же образом, как в XAML или XML (на примере Android Data Binding Library) описаны привязки. Я вижу MVVM.Все нормально, стоило. Извиняться тут не за что.
… потому что не знаем, что React не про реактивное программирование?