Комментарии 30
1)
Судя по всему вы даже не пытались найти, навскидку: MVVM Light, Caliburn.Micro
2)
Так а зачем тут Expression если вы примером выше воспользовались атрибутом, который подставляет сам имя target member? (разбор Expression Tree может ударить по перфомансу).
3)
Для этого есть более красивый EventToCommand behavior без засорения ViewModel
4)
Это уже MVP а не MVVM
6)
Для этого придумали Visual States + GoToState
7.
Опять же завязываетесь на View из ViewModel
мы искали библиотеку поддержки шаблона Model-View-ViewModel (MVVM) для этой платформы. Некоторое время провели в интернете в поиске таковой, но в итоге приняли факт, что таких библиотек в природе пока не существует
Судя по всему вы даже не пытались найти, навскидку: MVVM Light, Caliburn.Micro
2)
get { return GetPropertyValue(() => Text); }
Так а зачем тут Expression если вы примером выше воспользовались атрибутом, который подставляет сам имя target member? (разбор Expression Tree может ударить по перфомансу).
3)
3. Связывание обработчиков событий
Для этого есть более красивый EventToCommand behavior без засорения ViewModel
4)
Вызов методов View из ViewModel
Это уже MVP а не MVVM
6)
Триггеры событий для анимации
Для этого придумали Visual States + GoToState
7.
Привязывание контекстного меню
Опять же завязываетесь на View из ViewModel
Адски поддерживаю ваш комментарий. Те же вопросы возникли по прочтении.
По-моему, изобретен очередной трехколесник.
По-моему, изобретен очередной трехколесник.
Автору, конечно, сложно со всеми спорить о том, стоило ли писать эту библиотеку.
Но 25 скачек шаблона проекта в день помоему говорит что стоило!
И это качают не пользователи, а разработчики.
Но 25 скачек шаблона проекта в день помоему говорит что стоило!
И это качают не пользователи, а разработчики.
Ну не трехколесник. Просто взято всё что было в калибурне и System.Windows.Interactivity, скомпоновано и выложено в нугет. В принципе довольно удобно для тех кому подобное сделать либо лень либо не хватает мозгов.
Исходники бы ещё в паблик, а в целом молодцы
Исходники бы ещё в паблик, а в целом молодцы
Наше первое приложение под Windows 8 мы начали разрабатывать в марте 2012 года. MVVM Light выпустили поддержку W8 летом 2012. Caliburn.Micro ещё позже.
В том же MVVM Light нет ничего платформозависимого — можно было взять и выдрать всё нужное оттуда из реализации для Windows Phone пока не было официальной поддержки — заняло бы буквально пару минут.
Вот именно в этом и проблема MVVM Light, сплошная абстракция никакой связи с платформой, выкинули его после первого проекта. Долго смотрел на Caliburn.Micro, не лежит к нему душа слишком тяжелый, много не понятных решений в контексте WinRT наследие SL ему мешает.
Почитайте форумы за то время. У MVVM Light была серьёзная проблема под Windows 8. Отличие платформы не позволяло, например, реализовать подписку на события с помощью команд тем способом, который есть в MVVM Light. Были и другие проблемы.
Кроме того, многие не пробовали писать приложения под Windows RT. А там встают вопросы производительности в полный рост.
Кроме того, многие не пробовали писать приложения под Windows RT. А там встают вопросы производительности в полный рост.
1) Судя по всему вы даже не пытались найти, навскидку: MVVM Light, Caliburn.Micro
Вы это знаете или мнение имеете? Библиотека появилась именно потому что сушествующие не подходили по тем или инным параметрам.
2)get { return GetPropertyValue(() => Text); }
Так а зачем тут Expression если вы примером выше воспользовались атрибутом, который подставляет сам имя target member? (разбор Expression Tree может ударить по перфомансу).
Можно и так и подругому, по перфомансу сравнимо с атрибутом, но дает плюс при рефакторинге.
Ну рад за вас, сейчас ваша библиотека не имеет никакой ценности ввиду наличия упомянутых фраемворков, более того вам уже ни раз написали что у вас нарушение паттерна MVVM.
>>Можно и так и подругому, по перфомансу сравнимо с атрибутом, но дает плюс при рефакторинге
Да ладно? Разбор Expression Tree работает так же быстро как CallerMemberNameAttribute?
>>дает плюс при рефакторинге
Какой плюс у этого:
get { return GetPropertyValue(() => Text); }
перед этим:
get { return GetPropertyValue(); }
?
>>Можно и так и подругому, по перфомансу сравнимо с атрибутом, но дает плюс при рефакторинге
Да ладно? Разбор Expression Tree работает так же быстро как CallerMemberNameAttribute?
>>дает плюс при рефакторинге
Какой плюс у этого:
get { return GetPropertyValue(() => Text); }
перед этим:
get { return GetPropertyValue(); }
?
ну давай не будем про ценность
безусловно нарушение «Вызов методов View из ViewModel»
как раз для этого и сделан ElementWrapper, он позволяет делать такие нарушения «красиво»,
к сожалению не все контролы которые нам приходилось использовать поддерживают MVVM в чистом виде
ни раз написали что у вас нарушение паттерна MVVM
безусловно нарушение «Вызов методов View из ViewModel»
как раз для этого и сделан ElementWrapper, он позволяет делать такие нарушения «красиво»,
к сожалению не все контролы которые нам приходилось использовать поддерживают MVVM в чистом виде
1. Судя по всему вы даже не пытались найти, навскидку: MVVM Light, Caliburn.Micro
MVVM Light и Caliburn.Micro библиотеки хорошие. Но под Windows Runtime вам понадобиться решить ряд проблем.
2. Так а зачем тут Expression если вы примером выше воспользовались атрибутом, который подставляет сам имя target member? (разбор Expression Tree может ударить по перфомансу).
В статье показаны возможные варианты.
3. Для этого есть более красивый EventToCommand behavior без засорения ViewModel
В этом случае в XAML получится больше кода. Разве это красиво? И в чём будет состоять засорение модели в нашем методе?
4. Это уже MVP а не MVVM
Для MVP не хватает P. Вызовы представления через дополнительный слой вполне легитимны. Главное, что нет зависимости между моделью и представлением.
5. Этот пункт видимо был удалён.
6. Для этого придумали Visual States + GoToState
А ещё придумали триггеры, только не реализовали их в Windows Runtime. Посмотрите на WPF.
Кроме того, для переключения Visual States нужно писать код. А с триггерами всё делается в XAML.
7. Опять же завязываетесь на View из ViewModel
О чём Вы? Модель абсолютно ничего про представление здесь не знает.
Но под 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]}?
Всё это спорно. И вы всё время путаете то, что есть в Windows Runtime с тем, что вы привыкли использовать на других платформах и в других библиотеках.
Официальный ответ от Microsoft на вопрос про System.Windows.Interactivity: no official version of this dll available.
Возможно у вас есть адаптированная версия, или вы собрали кусочки из разных библиотек и доработали их как-то. У автора же есть решение, готовое для публики. Вы можете создать проект и получить всё это сразу «из коробки» прямо в Visual Studio.
«Просто создай проект и радуйся.»
Официальный ответ от Microsoft на вопрос про System.Windows.Interactivity: no official version of this dll available.
Возможно у вас есть адаптированная версия, или вы собрали кусочки из разных библиотек и доработали их как-то. У автора же есть решение, готовое для публики. Вы можете создать проект и получить всё это сразу «из коробки» прямо в Visual Studio.
«Просто создай проект и радуйся.»
Увы, это так. Конкретно про триггеры и GotoStateAction — winrttriggers.codeplex.com (там же EventTrigger+InvokeCommandAction == EventToCommand).
6. А как из вьюмодели вызвать GoToState? :))
У нас к примеру во вьюмодели есть свойство CallState (enum со значениями типа InCall, Ringing и т.п.) и есть такой behavior paste.org.ru/?7v7pyv, а дальше в XAML пшиется />
Тоже не плохо. Но код писать надо. Триггер вообще без лишнего кода работает. Для этого XAML и придумали, чтобы декларативно описывать представление. В общем по ситуации смотреть нужно, что лучше использовать. Состояния хороши, когда вы пишете контрол, у которого можно переопределить шаблон. Класс может как бы описать контракт, какие там есть состояния и части. Если же вы просто пишите UserControl или Page, и у вас нет каких-то специфиных состояний. А вы просто хотите, например, начать анимацию при загрузке контрола. То зачем вам все эти состояния? Повесил триггер на Loaded и готово.
Cостояние, которое я привел в пример — атрибут бизнес объекта (принадлежит предметной области), а не специальное свойсвто для UI (понятное дело во вьюмодели не должно быть объектов хранящих состояния контролов). Собсно, я отвечал на его вопрос:
>> А как из вьюмодели вызвать GoToState?
А вообще про триггеры и GoToStateBehavior я уже ни разу упомянул в этой теме ;-)
>> А как из вьюмодели вызвать GoToState?
А вообще про триггеры и GoToStateBehavior я уже ни разу упомянул в этой теме ;-)
>> Вызов методов View из ViewModel
ViewModel ничего не должна знать о View. Это нарушение паттерна.
А так очень рекомендую Caliburn.
MVVM Light не рекомендую, так как работал долго и понял, что это слишком Light с утечками памяти и тп. Он хорош только для быстрого прототипирования, но поддерживать его потом в продакшене сложнее.
ViewModel ничего не должна знать о View. Это нарушение паттерна.
А так очень рекомендую Caliburn.
MVVM Light не рекомендую, так как работал долго и понял, что это слишком Light с утечками памяти и тп. Он хорош только для быстрого прототипирования, но поддерживать его потом в продакшене сложнее.
Можно узнать, как его использовать так, чтобы получить утечки памяти? И как в этом поможет Caliburn?
Прочитайте статью внимательнее. Там как раз эта проблема решена. Модель вызывает представление через заглушки. То есть нет зависимости между моделью и представлением.
Если бы представление было бы ну совсем никак не вызвать из модели, то, например, было бы невозможно реализовать навигацию между страницами в рамках MVVM.
Если бы представление было бы ну совсем никак не вызвать из модели, то, например, было бы невозможно реализовать навигацию между страницами в рамках MVVM.
Спасибо автору за статью. Библиотека и правда очень полезная. Сами пользуемся уже некоторое время.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Варим MVVM для Windows Store-приложений