Cостояние, которое я привел в пример — атрибут бизнес объекта (принадлежит предметной области), а не специальное свойсвто для UI (понятное дело во вьюмодели не должно быть объектов хранящих состояния контролов). Собсно, я отвечал на его вопрос:
>> А как из вьюмодели вызвать GoToState?
А вообще про триггеры и GoToStateBehavior я уже ни разу упомянул в этой теме ;-)
У нас к примеру во вьюмодели есть свойство CallState (enum со значениями типа InCall, Ringing и т.п.) и есть такой behavior paste.org.ru/?7v7pyv, а дальше в XAML пшиется />
Это всеравно некоторое выставление контракта интерфейсу, через дополнительную абстракцию. К сожелению, в некоторых ситуациях по другому действительно не сделать.
Но под Windows Runtime вам понадобиться решить ряд проблем.
Обожаю такие конкретные ответы
В этом случае в XAML получится больше кода. Разве это красиво? И в чём будет состоять засорение модели в нашем методе?
Зато это будет чистое и универсальное решение, а у вас ограниченный набор захардкоденных событий. Кроме того модель будет с понятной командой ICommand.
Для MVP не хватает P. Вызовы представления через дополнительный слой вполне легитимны. Главное, что нет зависимости между моделью и представлением.
То что вы сделали — классическая реализация MVP, вы передали интерфейс вьюхи (в вашем случае враппер) в презентер (то что вы его назвали ViewModel, а не Presenter — ни о чем не говорит).
А ещё придумали триггеры, только не реализовали их в Windows Runtime. Посмотрите на WPF.
Кроме того, для переключения Visual States нужно писать код. А с триггерами всё делается в XAML.
Как минимум EventTrigger есть (см. System.Windows.Interactivity). Для переключения Visual States не нужно писать код. Достаточно воспользоваться GoToStateBehavior в XAML (и если его нет — написать самому не долго передрав реализацию для других платформ).
О чём Вы? Модель абсолютно ничего про представление здесь не знает.
Вы написал массив команд для контекстного меню, но что если вам где-то понадобится отдельно одна из команд в этом списке? Вы будете её дублировать во вьюмодели или напишите {Binding ContextMenuCommands[1]}?
Ну рад за вас, сейчас ваша библиотека не имеет никакой ценности ввиду наличия упомянутых фраемворков, более того вам уже ни раз написали что у вас нарушение паттерна MVVM.
>>Можно и так и подругому, по перфомансу сравнимо с атрибутом, но дает плюс при рефакторинге
Да ладно? Разбор Expression Tree работает так же быстро как CallerMemberNameAttribute?
>>дает плюс при рефакторинге
Какой плюс у этого:
get { return GetPropertyValue(() => Text); }
перед этим:
get { return GetPropertyValue(); }
?
В том же MVVM Light нет ничего платформозависимого — можно было взять и выдрать всё нужное оттуда из реализации для Windows Phone пока не было официальной поддержки — заняло бы буквально пару минут.
мы искали библиотеку поддержки шаблона Model-View-ViewModel (MVVM) для этой платформы. Некоторое время провели в интернете в поиске таковой, но в итоге приняли факт, что таких библиотек в природе пока не существует
Судя по всему вы даже не пытались найти, навскидку: MVVM Light, Caliburn.Micro
2)
get { return GetPropertyValue(() => Text); }
Так а зачем тут Expression если вы примером выше воспользовались атрибутом, который подставляет сам имя target member? (разбор Expression Tree может ударить по перфомансу).
3)
3. Связывание обработчиков событий
Для этого есть более красивый EventToCommand behavior без засорения ViewModel
Достали эти статьи про собеседования — одни пишут: «Ха, зацените какие идиоты к нам на собеседование приходят! Не отвечают даже на простейшие вопросы, но я такой крутой — всех режу», вторые жалуются на идиотов-интервьюверов\идиотские вопросы.
>> А как из вьюмодели вызвать GoToState?
А вообще про триггеры и GoToStateBehavior я уже ни разу упомянул в этой теме ;-)
Обожаю такие конкретные ответы
Зато это будет чистое и универсальное решение, а у вас ограниченный набор захардкоденных событий. Кроме того модель будет с понятной командой ICommand.
То что вы сделали — классическая реализация MVP, вы передали интерфейс вьюхи (в вашем случае враппер) в презентер (то что вы его назвали ViewModel, а не Presenter — ни о чем не говорит).
Как минимум EventTrigger есть (см. System.Windows.Interactivity). Для переключения Visual States не нужно писать код. Достаточно воспользоваться GoToStateBehavior в XAML (и если его нет — написать самому не долго передрав реализацию для других платформ).
Вы написал массив команд для контекстного меню, но что если вам где-то понадобится отдельно одна из команд в этом списке? Вы будете её дублировать во вьюмодели или напишите {Binding ContextMenuCommands[1]}?
>>Можно и так и подругому, по перфомансу сравнимо с атрибутом, но дает плюс при рефакторинге
Да ладно? Разбор Expression Tree работает так же быстро как CallerMemberNameAttribute?
>>дает плюс при рефакторинге
Какой плюс у этого:
get { return GetPropertyValue(() => Text); }
перед этим:
get { return GetPropertyValue(); }
?
Судя по всему вы даже не пытались найти, навскидку: MVVM Light, Caliburn.Micro
2)
Так а зачем тут Expression если вы примером выше воспользовались атрибутом, который подставляет сам имя target member? (разбор Expression Tree может ударить по перфомансу).
3)
Для этого есть более красивый EventToCommand behavior без засорения ViewModel
4)
Это уже MVP а не MVVM
6)
Для этого придумали Visual States + GoToState
7.
Опять же завязываетесь на View из ViewModel
— Я .NET разработчик
— Я зашел просто хаотически потыкать опросы
Pic: