MVVM(Model-View-ViewModel)アーキテクチャにおいて、コマンドパターンはユーザーインターフェースとビジネスロジックを疎結合に保つための重要な役割を果たします。標準の ICommand インターフェースを基盤としつつ、現代のアプリケーション開発で不可欠な非同期処理に対応するため、コマンドの実装は同期型から非同期型へと進化を遂げています。本稿では、MVVMヘルパーライブラリにおけるコマンドパターンの設計思想と、その実装詳細について技術的な観点から解説します。
コマンドパターンの基盤:非同期コマンドインターフェースの定義
標準の ICommand は同期的な実行を前提として設計されています。これに対し、非同期操作をネイティブにサポートするために、以下のような拡張インターフェースが定義されます。
public interface IAsyncCommand : ICommand
{
Task ExecuteAsync();
}
public interface IAsyncCommand<TParameter> : ICommand
{
Task ExecuteAsync(TParameter parameter);
}
これらのインターフェースは、非同期メソッドを直接バインディング可能にするための契約を提供し、UIスレッドのブロックを防ぐ設計の基盤となります。
同期コマンドの実装:デリゲートベースのCommandクラス
同期的な操作を扱うための基本クラスは、実行ロジックと実行可否の判定ロジックをデリゲートとして受け取ります。型安全性を確保するためのジェネリック版と、柔軟性を重視した非ジェネリック版が用意されています。
型安全なジェネリックコマンド
public class Command<T> : Command
{
public Command(Action<T> executeAction, Predicate<T> canExecutePredicate = null)
{
// 内部ステートとデリゲートの初期化
}
}
ジェネリック版は、コマンドパラメータの型をコンパイル時に保証し、キャスト処理に伴うランタイムエラーを防止します。
柔軟な非ジェネリックコマンド
public class Command : ICommand
{
public Command(Action executeAction, Func<bool> canExecuteFunc = null) { ... }
public Command(Action<object> executeAction, Func<object, bool> canExecuteFunc = null) { ... }
}
パラメータを必要としない、あるいは動的な型(object)を扱うシナリオにおいて、非ジェネリック版が有効です。
非同期コマンドへの進化:AsyncCommandの設計
ネットワーク通信やデータベースアクセスなどのI/Oバウンドな処理が増加するにつれ、非同期コマンドの必要性が高まっています。AsyncCommand は、タスクのライフサイクル管理、例外処理、および同期コンテキストの制御を内包しています。
パラメータなしの非同期コマンド
public class AsyncCommand : IAsyncCommand
{
public AsyncCommand(
Func<Task> taskFactory,
Func<bool> canExecute = null,
Action<Exception> exceptionHandler = null,
bool continueOnCapturedContext = false)
{
// 非同期実行エンジンとエラーハンドラの設定
}
}
パラメータ付き非同期コマンド
public class AsyncCommand<T> : IAsyncCommand<T>
{
public AsyncCommand(
Func<T, Task> taskFactory,
Func<T, bool> canExecute = null,
Action<Exception> exceptionHandler = null,
bool continueOnCapturedContext = false)
{
// 型付きパラメータに対応した非同期パイプラインの構築
}
}
continueOnCapturedContext フラグは ConfigureAwait の動作を制御し、デッドロックを回避しつつパフォーマンスを最適化します。また、exceptionHandler を注入することで、UIレイヤーに例外を伝播させることなく、ViewModel内でエラーを安全に処理できます。
パラメータ検証と型チェックの内部実装
XAMLバインディングではパラメータが object 型として渡されることが多いため、実行時の型検証が不可欠です。内部ユーティリティクラスがこれを担当します。
internal static class CommandParameterValidator
{
internal static bool IsCompatible<T>(object parameter)
{
if (parameter == null) return !typeof(T).IsValueType || Nullable.GetUnderlyingType(typeof(T)) != null;
return parameter is T;
}
}
型不一致が検出された場合、カスタム例外をスローすることで、開発者が早期にバインディングの誤りに気づけるように設計されています。
実践的なユースケースと実装パターン
基本的な同期アクション
var resetFormCommand = new Command(() => ClearInputFields());
パラメータ付きの同期アクション
var selectItemCommand = new Command<ItemModel>(
item => SetSelectedItem(item),
item => item != null && item.IsEnabled
);
基本的な非同期アクション
var refreshDataCommand = new AsyncCommand(async () => await FetchLatestRecordsAsync());
高度な非同期アクション(例外処理とパラメータ検証)
var submitOrderCommand = new AsyncCommand<OrderRequest>(
async request => await ProcessOrderAsync(request),
request => request.IsValid && !IsProcessing,
exceptionHandler: ex => LogErrorAndNotifyUser(ex),
continueOnCapturedContext: true
);
テスト容易性の確保
コマンドクラスはUIから独立しているため、ユニットテストが容易です。xUnitやNUnitなどのテストフレームワークを用いることで、Execute メソッドの呼び出し、CanExecute の状態遷移、および非同期タスクの完了待機を直接検証できます。これにより、ViewModelのビジネスロジックの堅牢性が保証されます。