Инфраструктура команд для вызова пользователем действий в шаблоне MVVM

[AlexP11223]

По-моему в статью следует добавить примеры кода и т.д., а не просто ссылки на гитхаб.

[novar]

добавил кода, надеюсь получилось не сильно тяжело для восприятия статьи

[Athari]

Команды, как они реализорваны в WPF — это боль: параметр один, нетипизированный; под каждый эвент нужно городить костыли, потому что свойство Command только одно; вью-модели замусориваются лишним кодом с созданием команд; и так далее и тому подобное. Когда начал использовать Caliburn.Micro, я про это боль забыл.

Что касается вашего кода, то почему везде object и приведения типов? Где дженерики?

Зачем вам связный список? Тем более велосипедный?

Почему комментарии на русском?

Неймспейсы странные… Вы бы придумали свой неймспейс и после него написали неймспейс под библиотеку, как принято.

[Athari]

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

[novar]

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

[novar]

Применение параметра в виде нетипизированного object принято в базовой библиотеке классов во всём что связано с задачами (Task). Также и в ICommand. Я просто последовал принятой практике.

Неизменяемый односвязный список нужен для обеспечения конкурентного доступа. «Невелосипедный» конкурентный список (например ConcurrentStack) будет явный перебор для такого простого применения.

Комментарии и пространства имён для многих странные, согласен. Тут личные причины. Не думаю что много вреда от этого.

[NeoNN]

Только два слова. Caliburn Micro.

[novar]

CM — это очень громоздкий монолитный фреймворк, заставляющий изучить и использовать совершенно новые способы построения приложений. Некоторые его части не соответствуют моему видению принципов построения приложений. Конкретно по теме статьи он мало чем может помочь: не помогает асинхронно запускать синхронные методы, не поддерживает отмену запущенных действий, не предоставляет статуса и исключений действий, не позволяет объединять их в группы не заморачиваясь с вычислением доступности для каждого и т.д.

[NeoNN]

Насчет асинхронного запуска синхронных методов blogs.msdn.com/b/pfxteam/archive/2012/03/24/10287244.aspx

[novar]

А что именно можно почерпнуть по ссылке? Там доказывают, что в библиотеках не надо выставлять (expose) асинхронные обёртки (wrapper) для синхронных методов, потому что запустить их асинхронно при необходимости и так нетрудно, а в некоторых случаях выгоднее вызывать их синхронно. В статье именно так и сделано: для сохранения отзывчивости интерфейса пользователя производится асинхронный вызов синхронных методов. Никто не создаёт и не выставляет для них обёртки.

[NeoNN]

Да, все верно. Особой привязки статьи к обсуждаемому коду нет.