Comments 15
А можно как-то упростить до
Чтобы автоматом потом скомпилировался нужный геттер и сеттер с RaiseAndSetIfChanged.
Очень уж много однообразного кода.
[SomeoneAttribute]
public string Something {get;set;}
Чтобы автоматом потом скомпилировался нужный геттер и сеттер с RaiseAndSetIfChanged.
Очень уж много однообразного кода.
https://github.com/demigor/kindofmagic
Если подобные объекты создавать фабриками, то есть довольно простое решение — динамические прокси-классы. Свойства делаем виртуальными, в прокси-классе переопределяем с нужным поведением.
Есть Fody, на его основе сделана реализация
— для классического INPC: https://github.com/Fody/PropertyChanged
— для ReactiveUI: https://github.com/kswoll/ReactiveUI.Fody
Но я не пользовался ни той, ни другой, не могу сказать, насколько это удобно и есть ли какие-то подводные камни.
— для классического INPC: https://github.com/Fody/PropertyChanged
— для ReactiveUI: https://github.com/kswoll/ReactiveUI.Fody
Но я не пользовался ни той, ни другой, не могу сказать, насколько это удобно и есть ли какие-то подводные камни.
Подводных камней нет, оно даже зависимости между свойствами видит и триггерит по цепочке несколько событий, когда свойство меняется
То, что можно не писать геттеры-сеттеры и оставить просто автосвойство — действительно здорово. Надо будет попробовать… А вот что касается магии цепочек эвентов: полагаю, это работает только в самых простых случаях, когда я использую первое свойство в геттере второго?
Вы не испытываете проблем с тем, что если надо немного усложнить логику изменения Output Property, приходится отказываться от автосвойсв и начинать руками триггерить эвенты? И не получается ли в итоге непонимания, что в коде происходит автоматически, что делается руками и как оно вообще работает в целом?
Вы не испытываете проблем с тем, что если надо немного усложнить логику изменения Output Property, приходится отказываться от автосвойсв и начинать руками триггерить эвенты? И не получается ли в итоге непонимания, что в коде происходит автоматически, что делается руками и как оно вообще работает в целом?
Технически есть один небольшой подводный камень:
ReactiveUI.Fody не добавляет свой weaver автоматически в FodyWeavers.xml. <ReactiveUI/> туда надо добавлять ручками. И если банально забыть это сделать, то приложение спокойно скомпилится, но не будет правильно работать, а разработчик будет голову ломать в чем же проблема, когда вроде бы все правильно написано. Сам несколько раз так попадался :)
Еще раньше была проблема, если в FodyWeavers.xml добавить weaver для ReactiveUI, но при этом ни в одном из файлов проекта не использовать аттрибуты вивера ([Reactive], [ObservableAsProperty]). Такое бывает когда добавляется сразу несколько проектов-заготовок в новый солюшн. Тогда проект не компилился из-за какой-то ошибки. Точно ошибку не помню, но она была, по-моему, не слишком очевидной. Сейчас, кажется, проблема исправлена.
ReactiveUI.Fody не добавляет свой weaver автоматически в FodyWeavers.xml. <ReactiveUI/> туда надо добавлять ручками. И если банально забыть это сделать, то приложение спокойно скомпилится, но не будет правильно работать, а разработчик будет голову ломать в чем же проблема, когда вроде бы все правильно написано. Сам несколько раз так попадался :)
Еще раньше была проблема, если в FodyWeavers.xml добавить weaver для ReactiveUI, но при этом ни в одном из файлов проекта не использовать аттрибуты вивера ([Reactive], [ObservableAsProperty]). Такое бывает когда добавляется сразу несколько проектов-заготовок в новый солюшн. Тогда проект не компилился из-за какой-то ошибки. Точно ошибку не помню, но она была, по-моему, не слишком очевидной. Сейчас, кажется, проблема исправлена.
ReactiveUI.Fody не добавляет свой weaver автоматически в FodyWeavers.xml. <ReactiveUI/> туда надо добавлять ручками. И если банально забыть это сделать, то приложение спокойно скомпилится, но не будет правильно работать, а разработчик будет голову ломать в чем же проблема, когда вроде бы все правильно написано. Сам несколько раз так попадался :)
В 2019 это наконец починили на уровне Fody. Теперь, при установке любого weaver-а, запускается задача MSBuild, которая создаёт FodyWeavers.xml в корне проекта с включённым установленным плагином, либо модифицирует существующий FodyWeavers.xml!
Я сейчас использую Fody PropertyChanged (первая ссылка выше) на паре проектов, один на Caliburn Micro, второй на Prism. Получается очень удобно, никаких проблем нет. А то, что он автоматически обрабатывает зависимости между свойствами, очень сильно упрощает код. Кстати, работает этот плагин в том числе и с Reactive UI.
del
Попробовал ReactiveUI.Fody, описал подробнее в следующей части: https://habrahabr.ru/post/303898/
Получилось как раз как в вашем примере.
Получилось как раз как в вашем примере.
Документацию может заменить этот сайт www.introtorx.com
Как раз сегодня начал разбираться с ReactiveUI, захожу на хабр и вижу вашу статью. Очень жду продолжения!
Sign up to leave a comment.
Введение в ReactiveUI: прокачиваем свойства во ViewModel