Pull to refresh

Comments 11

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

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

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

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

Неймспейсы странные… Вы бы придумали свой неймспейс и после него написали неймспейс под библиотеку, как принято.
Ну и пример нужно было осмысленный делать, а не непонятно что с абстрактными действиями. В примере нужно демонстрировать крутизну библиотеки на реалистичных задачах, а не запугивать тонной абстракций.
Мой пример, я считаю, не содержит тонны абстракций. Он представляет собой почти минимальное приложение соответствующее шаблону MVVM. Моя задача была показать применение именно по шаблону. Я думаю, что реальные приложения так и должны выглядеть.
Применение параметра в виде нетипизированного object принято в базовой библиотеке классов во всём что связано с задачами (Task). Также и в ICommand. Я просто последовал принятой практике.

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

Комментарии и пространства имён для многих странные, согласен. Тут личные причины. Не думаю что много вреда от этого.
CM — это очень громоздкий монолитный фреймворк, заставляющий изучить и использовать совершенно новые способы построения приложений. Некоторые его части не соответствуют моему видению принципов построения приложений. Конкретно по теме статьи он мало чем может помочь: не помогает асинхронно запускать синхронные методы, не поддерживает отмену запущенных действий, не предоставляет статуса и исключений действий, не позволяет объединять их в группы не заморачиваясь с вычислением доступности для каждого и т.д.
А что именно можно почерпнуть по ссылке? Там доказывают, что в библиотеках не надо выставлять (expose) асинхронные обёртки (wrapper) для синхронных методов, потому что запустить их асинхронно при необходимости и так нетрудно, а в некоторых случаях выгоднее вызывать их синхронно. В статье именно так и сделано: для сохранения отзывчивости интерфейса пользователя производится асинхронный вызов синхронных методов. Никто не создаёт и не выставляет для них обёртки.
Sign up to leave a comment.

Articles