Здравствуйте, Kolesiki, Вы писали:

K>Здесь {} — сокращение для Binding, [] — вызвать функцию из кода, "" — задать значение напрямую.
K>Ну чем тебе не идеал?

Не XML-валидно.

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, Kolesiki, Вы писали:

K>>Здесь {} — сокращение для Binding, [] — вызвать функцию из кода, "" — задать значение напрямую.
K>>Ну чем тебе не идеал?

S>Не XML-валидно.

А наплевать. XAML — это худшее, что есть в WPF. Тот же ammy, который ionoy сделал в 100 приятнее. К сожалению чтоб оно взлетело нужно, чтоб такую такую штуку MS делал.

Здравствуйте, Qbit86, Вы писали:

Q>Здравствуйте, Shmj, Вы писали:

S>>Получается, что никакого реального преимущества, кроме хайпа, нет

Q>Ни так, ни эдак делать не нужно. И декларативное vs. императивное тут ни при чём.

Q>Конвертер не нужен. Потому что ViewModel — это и есть конвертер на стероидах. Должна быть привязка к свойству во вью-модели того же типа, что требуется для GUI. А уж внутри этого свойства мапь из низлежащих данных хоть императивно, хоть декларативно. На внешнем уровне всё останется декларативным.

Q>Вместо этого:
Q>

<Window.Resources>
Q>        <local:DateBacklightConverter x:Key="dateBacklightConverter" />
Q></Window.Resources>

Q><TextBox Text="{Binding Date}" Background="{Binding Source=Date,Converter={StaticResource dateBacklightConverter}}" />

Q>останется это:
Q>

<TextBox Text="{Binding DateString}" Background="{Binding DateColor}" />

Если потребуется изменить цвет подсветки, то нам потребуется вносить изменения в ViewModel. Было бы лучше если бы нам для этого потребовалось изменить лишь style в разметке.

Здравствуйте, Qulac, Вы писали:

Q>>

<TextBox Text="{Binding DateString}" Background="{Binding DateColor}" />

Q>Если потребуется изменить цвет подсветки, то нам потребуется вносить изменения в ViewModel.

В исходном примере тоже потребовалось бы вносить изменение в код — в конвертере.

Q>Было бы лучше если бы нам для этого потребовалось изменить лишь style в разметке.

Чем лучше? Кому лучше?

Здравствуйте, Shmj, Вы писали:

S>Почему все верят, что декларативный подход рулит и на порядок упрощает работу?

разработка софта в отличие от, например, строительства еще очень молода.
Люди ищут оптимальные подходы. Какое-то время казалось, что отделить разработку форм от обработки данных хорошая идея.
Скорее всего причина только в этом. Есть разные идеи и у каждой есть сторонники.
Но лично мое мнение, что победит "код как данные", посмотрите на успех elm, кложури и кложескрипта, https://github.com/fsprojects/Fabulous
websharper, fsbolero и т.п.
Любой UI это иерархия элементов(связанный список), если у нас в ЯП есть "list comprehension"(удобный для понимания человеком способ представления списков),
то проще и эффективней описать UI именно так. Отображение данных при этом на порядок упрощается, так же как и DRY и прочие вещи.
UPDATE. еще очевидный плюс — один яп вместо местного диалекта (XAML и т.п.) или привязка к дизайнеру(который еще и чувствителен к изменениям).

Здравствуйте, Shmj, Вы писали:

S>Декларативный подход типа:

Ты путаешь декларативный и Xaml. Xaml — дерьмо.

S>

TextBox Text=Date Background=dateBacklightConverter(Date)
S>

Дальше твои рассуждения я скипнул.

Здравствуйте, Shmj, Вы писали:

S>Почему все верят, что декларативный подход рулит и на порядок упрощает работу?

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

S>Вот, давайте на примере.

Тут проблемы две.
1. В ВПФ декларативность убогая. Сам язык разметки — убогий. Программирование на ХМЛ, плюс динамическая типизация, плюс кране скудная и не удобная расширяемость. Вот если взять хотя бы АММИ, то расклад меняется.
2. Ты решаешь только одну задачу — отображение данных. И сравниваешь только объем кода. А в реальности задач бывает куда больше.

Вот смотри. У нас ГУЙ решает следующие задачи:
1. Переиспользование воью-моеделей.
2. Локализация.
3. Тестирование. Тестируется сам продукт, но через дерганье вью-моделей.
4. Отделение верстки от кода логики. Программист только рисует набросок формы и реализует ВМки с биндингом, а уже за реальное визуальное представление отвечают проффесионалы в верстке. Перередически производится рескининг (смена внешниего вида).
5. Реактивность и гибкость ГУя.
6. Автоматически снять скриншоты для всех переводов и для всех состояний, чтобы переводчики могли проверить правильность переводов и не были вынуждены протыкивать весь продукт годами (форм море).

S>Есть поле на форме, вам нужно установить дату и подсветить, если дата нечетная.

S>Императивный подход (примерно):

S>

S>DateTextBox.Text = UIConverter.ConvertToText(businessObject.Date);

S>if (businessObject.Date.IsOdd)
S>   DateTextBox.Background = Color.Red;
S>

И вот теперь нам нужно поменять цвет. Нам придется править код.
Далее нам нужно оттестировать все это. А присвоения хер знает где. Мы не можем тупо присвоить дату в ВМке и быть уверенным, что гуй ее отобразит как надо.
Следующая задача — локализация. Мы должны опять таки править код.
И так далее.

S>Декларативный подход типа:

S>

S><Window.Resources>
S>        <local:DateBacklightConverter x:Key="dateBacklightConverter" />
S></Window.Resources>

S><TextBox Text="{Binding Date}" Background="{Binding Source=Date,Converter={StaticResource dateBacklightConverter}}" />
S>

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

Но согласен, что читабельность у этого птичьего языка не высока.

Правильно это бы выглядело как-то так:

using dateBacklightConverter=X.Y.X.dateBacklightConverter;
...
TextBox { Text=Date; Style=dateBacklightConverter(Date); }

Или даже:

using dateBacklightConverter=X.Y.X.dateBacklightConverter;
...
TextBox { Text=Date; Style=Date.IsOdd ? Normal : Highlighted; }

То есть это вопрос грамотной реализации языка попсания вьюх.

S>Теперь давайте какие реальные плюсы у т.н. декларативного? Букв меньше не стало.

У меня стало.

S>Совокупная сложность кода не понизилась

1. Код раделен на представление и ВМку. Теперь его можно тестировать.
2. Его внешний вид определяется стилями не связанными с кодом. Стало быть их можно легко менять.
3. Наш код реактивен, а значит его легче тестировать.
4. Мы можем переиспользовать ВМки в других вьюшках.

S> — все равно в конвертере есть проверка if и выбор цвета.

Да, логика представления никуда не девается. И если это однократное использование, то проще было бы описать его по месту.
Но если таких использований сони (что бывает часто в больших продуктах), то таки выгоднее вынести ее в отдельное место.

S>В XML-е писать не удобнее, но даже не в этом суть.

Полностью согласен. ХМЛ — плохой язык для программирования, а вьюхи все равно являются кодом, хоть и декларативным.

Еще минус — динамическая природа ВПФ. Но кое-ка ее обуздывает Решарпер и Райдер (в студии поддержка — говно).

S>Получается, что никакого реального преимущества, кроме хайпа, нет

Ты ее не там ищешь.

Смысл в разделении визуального представления и кода. Пока у тебя 2 строки, преимущества такого подхода не особо видны. Но если кода море, то смешивание логики представления и логики данных дает страшную кашу.

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

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

В общем, сама идея раздения на представления и модели-представлений — здравая. ХМЛ — идиотизм! Динамка — астдай! То что ВМки нужно руками выписывать (все эти
INotifyPropertyChanged — тоже оверхэд).

Идеальное решение мне видится следующим образом:
1. Все вьюхи должны иметь статически заданный тип ВМки (контролируется ИДЕ и компилятором). При этом допускается сабтайпинг на интерфейсах.
2. Вьюхи должны поддерживать паттерн матчинг по типам сабатйпинга.
3. Во вьюхах должен использоваться специально разработанный для этого язык без всяких ХМЛ-ей или джейсонов.
4. Во вьюхах должны поддерживаться гибкие операторы как в нормальных императивных языках.
5. Для описания ВМок язык должен поддерживать зависимые вычисления (как ленивость в Хаскеле). Это позволит обойтись без костылей в виде
INotifyPropertyChanged. Просто пишешь:

view model MyVM
{
  dependent string   PropX = PropY + 42 + PropZ;
  dependent string   PropY = DoSome(PropA, PropB);
  dependent int      PropA;
  dependent DateTime PropB;
  ...
  void Init()
  {
    PropA = ReadFromDb(...);
  }

  string DoSome(int x, DateTime y) { какие-то вычисления }
}

view MyView
{
   TextBox   { Text=PropB; Style=A; }
   TextBlock { Text=PropA; Style=B; }
   TextBlock { Text=PropZ; Style=B; }
}

И все вычисления распространяются автоматически. При этом все статически проверяется при компиляции и в ИДЕ.

Ну, а стили должны быть как в CSS, а не как в ВПФ в виде наборов присвоений свойств, триггеров и шаблонов верстки (бррр!).

Здравствуйте, Qbit86, Вы писали:

Q>Ни так, ни эдак делать не нужно. И декларативное vs. императивное тут ни при чём.

Q>Конвертер не нужен. Потому что ViewModel — это и есть конвертер на стероидах. Должна быть привязка к свойству во вью-модели того же типа, что требуется для GUI.

Нет, это нарушает идеологию MVVM. VM-а не должна думать о форматировании данных или их визуальном представлении. В идеале VM-ка должна только содержать сами данные.

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

Q>А уж внутри этого свойства мапь из низлежащих данных хоть императивно, хоть декларативно. На внешнем уровне всё останется декларативным.

Грош цена такой декларативности. Нет, возня с конвертерами это суровая действительность. И сделано это в ВПФ крайне убого и неудобно.

Я за последние 3 месяца насмотрелся хардкорного ВПФ-а с многометровыми простынями, которые не увидеть в дизайнере, и которые без пол литры не поймешь. Но соображения тестируемости, локализуемости и легкой смены визуального представления требуют иметь VM-ки с сырыми данными, а все визуальные навороты (включая перевод, форматирование и т.п.) производить только через конвертеры.

Можно конечно вводить иерархии ВМ-ок, где одна из них хранит сырые данные, а другая локализованные и приведенные к нужным типам. Но своего рода костыль вызванный убогостью ВПФ-а.

Здравствуйте, Владимир35, Вы писали:

В>Что нужно сделать для создания ГУИ императивно? Даже подумать страшно. Определенные императивные технологии, и некоторые причисляющие себя к "декларативным", такого в принципе не поддерживают.

Это вопрос навороченности контролов. То что ВПФ позволяет делать иерархические верстки не заслуга MVVM, а заслуга архитектуры ВПФ. Та же херня в HTML, хотя там исходно MVVM-ом и не пахло, а ветки можно менять императивно.

Да и ВПФом можно спокойно возиться императивно.

Причем в ВПФ-е море подводных граблей (тм). Это и ретемлейтинг с необходимостью менять пол контрола. И данамика в связывании. И сложная отладка (почти никакая). И дебильная императивность стилей (это не стили, а какие-то императивные конструкции, в которых море присвоений свойств и откровенных шаблонов верстки). Короче один стеэоверфлоу-программинг.

В общем, хорошая идея с MVVM и гибкостью контролов, но хреновая реализация самоего языка.

Здравствуйте, VladD2, Вы писали:

Q>>Конвертер не нужен. Потому что ViewModel — это и есть конвертер на стероидах. Должна быть привязка к свойству во вью-модели того же типа, что требуется для GUI.

VD>Нет, это нарушает идеологию MVVM. VM-а не должна думать о форматировании данных или их визуальном представлении. В идеале VM-ка должна только содержать сами данные.

VM переводится как модель представления. Не представление модели.

VD>В идеале VM-ка должна только содержать сами данные.

Тогда это и будут данные. Просто ещё один слой модели. То, что скрывается за буквой M в аббревиатуре MVVM.

VD>Представь, что твой продукт должен быть локализован на десятки языков, а тебе нужно оттестировать ее. И вот ты возвращаешь из нее текст, а потом плюешься в тестах, так как он на разных языках разный.

Это вообще ортогонально ViewModel'у. Тестирование — это сверка ожидаемого/желаемого значения и фактического/наблюдаемого значения. Если ты при сверке рассчитываешь ожидаемые значения, передавая одни параметры (язык), и рассчитываешь фактические значения, передавая другие параметры — то кто ж тебе виноват? Не ViewModel же.

Q>>А уж внутри этого свойства мапь из низлежащих данных хоть императивно, хоть декларативно. На внешнем уровне всё останется декларативным.

VD>Грош цена такой декларативности.

А тут не декларативность нужна как терминальная цель, а чтоб было просто и удобно. Задавать отображение в обычном C#-коде — просто и удобно. Пропихивать через нетипизированные аргументы контекст в отдельный бойлерплейт-конвертер и запариваться с его инстанцированием в XAML — это не просто и не удобно. Не делайте так.

VD>Нет, возня с конвертерами это суровая действительность.

Сам себе её навязал, сам мучаешься.

VD>И сделано это в ВПФ крайне убого и неудобно.

Поэтому «возни с конвертерами» стоит избегать. Терпеть это ради эфемерного хз чего, ещё и защищать — ментальная ловушка.

Здравствуйте, Qbit86, Вы писали:

Q>VM переводится как модель представления. Не представление модели.

И что? По факту это все равно модель, и связь ее с представлением должна ограничиваться биндингом. Никакой логики представления в ней быть не должно.

Q>Тогда это и будут данные. Просто ещё один слой модели. То, что скрывается за буквой M в аббревиатуре MVVM.

Так это и есть еще один слой модели адаптирующий ее к отображению. Например, в модели у нас тупо список файлов, а в ВМке ее картинка, короткое имя...

Q>Это вообще ортогонально ViewModel'у. Тестирование — это сверка ожидаемого/желаемого значения и фактического/наблюдаемого значения. Если ты при сверке рассчитываешь ожидаемые значения, передавая одни параметры (язык), и рассчитываешь фактические значения, передавая другие параметры — то кто ж тебе виноват? Не ViewModel же.

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

Конвертеры и расширения решают данную проблему. Вся логика представления остаётся в представлении. Проблема только в том, что конвертеры громоздки и синтаксис КЗАМ-ла убог.

Q>А тут не декларативность нужна как терминальная цель, а чтоб было просто и удобно. Задавать отображение в обычном C#-коде — просто и удобно. Пропихивать через нетипизированные аргументы контекст в отдельный бойлерплейт-конвертер и запариваться с его инстанцированием в XAML — это не просто и не удобно. Не делайте так.

Дык это проблема языков, а не подхода. КЗАМЛ — действительно говноязык. Динамика — масдай. Но тогда надо уже думать об отказе от КЗАМЛа, а не аргументировать его кривизной нарушение модели.

Да, наверно проще зафигачить в ВМку свойство типа UIElement.Visibility. Но это нарушает модель. Да кода будет меньше. Да он даже будет гибче. Но в ВМке у тебя будет логика представления, а не адаптация модели. Ты будешь оперировать понятием видимости на экране, а не понятиями предметной области.

Например, свойство в ВМке должно называться SomeDataFound и иметь тип bool, а его биндинг с видимостью некоторых элементов должен быть через конвертер, а не LayoutForSomeDataVisibility с типом UIElement.Visibility. Последнее приводит к смешиванию логики представлены и логики модели, что неминуемо приведет каше и усложнению разработки.

Q>Сам себе её навязал, сам мучаешься.

Ее навязывает неудачная реализация. Нет проблем сделать язык верстки достаточно гибгим и удобным. То что МС этого не сделал не проблема модели (подхода), а проблема реализации.

Да, КЗАМЛ в реальном применении читается чудовищно плохо. Да все эти конвертеры и многословность их применения приводит к раздуванию кода представлений. Но все равно разделение дает неоспоримо большие преимущества.

Ну, и уж если выбирать твой подход, стоит подумать о модели MVVVM, т.е. еще одного промежуточного уровня содержащего только логику представления (локализацию, конвертацию и т.п.), а в предыдущей ВМке держать именно логику модели адаптированной к отображению, т.е. того что и должно называться ВМ.

Q>Поэтому «возни с конвертерами» стоит избегать. Терпеть это ради эфемерного хз чего, ещё и защищать — ментальная ловушка.

Нет. По этому приходится это говно терпеть. От части помогает Райдер. Там не плохая типизация сделана. Но по уму нужно прикрутить качественный фрэнтэд в котором не будет ХМЛ-я, будет полноценная типизация, и необходимые языковые средства спасающие от недостатков ВПФ.

Как вариант создание нормальной верстальной технологии, которая бы позволяла вообще не читать КЗАМЛ, а верстать все в визивидьж-виде (дизайнерами). Но этот подход тоже в ВПФ полностью провален, так как тот что есть дико тормозит, а конвертеры и расширения и вовсе убивают его и в реальном приложении дизайнер на фиг отключают и трахаются с прямым редактированием КЗАМЛа.

По факту МС просто забил на ВПФ. Технология потихоньку дохнет.

Возможно на смену ему придет Брэйзер. Но там точно такие же проблемы и еще свои.

Здравствуйте, VladD2, Вы писали:

VD>По факту это все равно модель, и связь ее с представлением должна ограничиваться биндингом.

Всё так, у тебя из ViewModel'а нет прямых ссылок на вьюшкины _button1'ы. Но она не то что должна ограничиваться биндингом. Она должна обслуживать этот биндинг. Это единственное назначение VM в MVVM. Никакой другой самостоятельной ценности или философии у этого архитектурного паттерна нет. Если в GUI-платформе нет движка привязок, то там будут MVC, MVP, Model-View-Whatever; но не MVVM. Его нужно применять так, чтобы чтобы было удобно использовать привязки. А жертвовать удобством привязок в пользу каких-то притянутых за уши требований — это misuse.

VD>Никакой логики представления в ней быть не должно.

Это противоречит общепринятому пониманию паттерна:

The view model of MVVM is a value converter,[1] meaning the view model is responsible for exposing (converting) the data objects from the model in such a way that objects are easily managed and presented. In this respect, the view model is more model than view, and handles most if not all of the view's display logic...
The view model is an abstraction of the view exposing public properties and commands.
— https://en.wikipedia.org/wiki/Model–view–viewmodel

VD>Так это и есть еще один слой модели адаптирующий ее к отображению. Например, в модели у нас тупо список файлов, а в ВМке ее картинка, короткое имя...

Да, ViewModel — это модель, только не модель модели. Это модель представления.

VD>Если у тебя ВМка начинает содержать логику представления...

the view model is more model than view, and handles most if not all of the view's display logic.
— https://en.wikipedia.org/wiki/Model–view–viewmodel

VD>...усложняешь переиспользование ВМки в других представлениях.

А можно какой-нибудь нетривиальный пример переиспользования VM'ки? Подойдёт какая-нибудь библиотека классов с nuget.org, где предлагаются осмысленные вью-модели для повторного использования.

VD>Конвертеры и расширения решают данную проблему.

Какую-то выдуманную проблему «переиспользования вью-моделов»?

VD>Вся логика представления остаётся в представлении.

Так ты ж всё равно пишешь конвертеры в C# коде? Где на две строчки логики приходится десять строчек бойлерплейта и кастов?

VD>Да, наверно проще зафигачить в ВМку свойство типа UIElement.Visibility. Но это нарушает модель. Да кода будет меньше. Да он даже будет гибче. Но в ВМке у тебя будет логика представления, а не адаптация модели.

Именно логика представления и должна быть в VM'ке. Если использовать каноничный MVVM, а не чей-то вымышленный одноимённый паттерн.

VD>Ты будешь оперировать понятием видимости на экране, а не понятиями предметной области.

Кто-то же должен оперировать понятием видимости на экране?

VD>Например, свойство в ВМке должно называться SomeDataFound и иметь тип bool, а его биндинг с видимостью некоторых элементов должен быть через конвертер, а не LayoutForSomeDataVisibility с типом UIElement.Visibility. Последнее приводит к смешиванию логики представлены и логики модели, что неминуемо приведет каше и усложнению разработки.

Логика представления — в модели представления (ViewModel). Логика модели — в модели модели (Model). Вот и всё.
В применении к этому примеру. В VM'ке может быть «ссылка на модель», в данном случае backing field _someDataFound: bool (или не быть, если достаточно целевого типа). А для привязки публиковаться свойства целевого типа: SomeDataFoundVisibility: Visibility, SomeDataFoundColor: Color (серый, если не найден), etc. Геттеры этих свойств и будут конвертерами из модели в представление. Всё просто и плоско, и минимизирует количество синтаксического мусора в разметке.

VD>Но все равно разделение дает неоспоримо большие преимущества.

Пока насчитывается ровно ноль «неоспоримо больших преимуществ». Наоборот, вместо решения поставленных задач разработчик занят генерёжкой BooleanToVisibilityConverter'ов ради удовлетворения фантазий о воображаемом переиспользовании ViewModel'ов. А можно просто использовать ViewModel по его прямому назначению.

Здравствуйте, Shmj, Вы писали:

S>Почему все верят, что декларативный подход рулит и на порядок упрощает работу?

Вера и религия не свойственна программистам!
Что то проще сделать декларативно, а что то программно.
В том же WPF Xaml можно применять как декларативный так и программный подход.
https://metanit.com/sharp/wpf/11.php

В тех же Win Forms можно работать и через дизайнер и программно.
Все зависит от условий. И можно сочетать эти два подхода вместе