.NETジェネリックを使用した元に戻す/やり直し機能の自動化

Sergey Arkhipenkoによる.NET GenericsによるUndo / Redoの自動化による翻訳記事。

はじめに

この記事では、アプリケーションのすべてのアクションに対して元に戻す/やり直し機能を提供するライブラリについて説明します。 複雑なデータ構造と複雑なアルゴリズムは、ユーザーの要求またはエラーの結果として、以前の状態にどのように転送されるかを考えることなく使用できます。

背景

複雑なデータ用のグラフィックエディターまたはデザイナーを開発したことがある場合は、アプリケーション全体でサポートされる元に戻す/やり直し機能を実装するという時間のかかるタスクに直面しています。 各操作にペアのDoメソッドとUndoメソッドを実装することは、電卓よりも深刻な何かを開発する場合、退屈でエラーが発生しやすいプロセスです。 実験の結果、元に戻す/やり直しのサポートをビジネスロジックに対して透過的にする方法を見つけました。 これを実現するために、ジェネリックの魔法を使用します。

このプロジェクトはCodePlexで公開されているため、誰でも使用したり貢献したりできます。

コードの使用

良いニュースが2つあります。 まず、データクラスのパブリックプロパティを変更する必要はありません。 プライベートフィールドは通常とは異なる方法で宣言するだけです。 第二に、ビジネスロジックも変更する必要がありません。 必要なのは、このコードの開始と終了をトランザクションのようにマークすることだけです。 したがって、コードは次のようになります。



UndoRedoManager.Start( "My Command" ); //



myData1.Name = "Name1" ;

myData2.Weight = 33;

myData3.MyList.Add(myData2);



UndoRedoManager.Commit(); //







このブロックのすべての変更を1行のコードでロールバックできます。



UndoRedoManager.Undo();







次の行は、元に戻された変更を再度適用します。



UndoRedoManager.Redo();







操作に参加したオブジェクトの数や使用されたデータの種類に関係なく、すべての変更を1つのトランザクションの結果として適用/キャンセルできることに注意してください。 参照とデータ型の両方を値で操作できます。 UndoRedoFrameworkは、ListおよびDictionaryデータ型もサポートしています。 データクラスを宣言し、この機能を実装する方法を見てみましょう。 一番下の行は、プライベートフィールドを特別なジェネリック型UndoRedo <>でラップする必要があるということです。



class MyData

{

private readonly UndoRedo name = new UndoRedo< string />( "" );



public string string Name

{

get { return name.Value; }

set { name.Value = value ; }

}

//...



}







以下は、前の例と比較できるように、補助フィールドを持つ古典的なプロパティ宣言です。



class MyData

{

private string name = "" ;



public string string Name

{

get { return name; }

set { name = value ; }

}

//...



}







これらのコードスニペットには、3つの重要な違いがあります。

• 補助フィールドにUndoRedo <>ジェネリック型を使用しています。 フィールド自体は値を保存しませんが、値を保存するコンテナを参照します。
• ヘルパーフィールドにアクセスする必要がある場合、nameの代わりにname.Valueを使用します。 name.Valueが型キャストなしで使用されていることがわかります。 これは、Valueのタイプが常にUndoRedo <...>括弧で囲まれているためです。
• プライベートフィールドは読み取り専用です。 これは、フィールドが変更情報の保存を担当するコンテナであるためです。 親エンティティが存在する限り存在する必要があります。 コンテナ自体を変更する必要はありませんが、もちろんValueを変更できます。

このソリューションは、参照型と値型の両方で機能します。

実装

実装の詳細に興味がない場合は、次のセクションに安全に進むことができます。 この記事では、いくつかの基本的な実装の詳細のみに注目します。 詳細については、ソースコードをご覧ください。 簡潔で十分にシンプルです。 フレームワークの主なクラスは、UndoRedoManagerとUndoRedo <>です。 UndoRedoManagerは、コマンドを操作するための静的メソッドを含むファサードクラスです。 以下はメソッドの部分的なリストです。



public static class UndoRedoManager

{

public static IDisposable Start( string commandCaption) { ... }



public static void Commit() { ... }

public static void Cancel() { ... }



public static void Undo() { ... }

public static void Redo() { ... }



public static bool CanUndo { get { ... } }

public static bool CanRedo { get { ... } }



public static void FlushHistory() { ... }

}







UndoRedoManagerクラスに加えて、次のオブジェクトがフレームワーク操作を提供します。

• UndoRedoManager
• 歴史
• コマンド
• 変更
• OldValue、NewValue

つまり、UndoRedoManagerはコマンドの履歴を保持します。 各チームには、独自の修正リストがあります。 各Changeオブジェクトには、古い値と新しい値が格納されます。 Changeオブジェクトは、ユーザーが変更を加えるとUndoRedo（）クラスによって作成されます。 覚えているように、上記の例で補助フィールドを宣言するときにUndoRedo（）クラスを使用しました。 このクラスは、Changeオブジェクトを作成し、それに古い値と新しい値を設定します。 このクラスの主要な部分は次のとおりです。



public class UndoRedo : IUndoRedoMember

{

//...



TValue tValue;



public TValue Value

{

get { return tValue; }

set

{

if (!UndoRedoManager.CurrentCommand.ContainsKey( this ))

{

Change change = new Change();

change.OldState = tValue;

UndoRedoManager.CurrentCommand[ this ] = change;

}

tValue = value ;

}

}

//...



}







上記のコードは、フレームワーク全体の重要な部分です。 前のセクションで発表したカスタムプロパティ内でどのように変更がキャプチャされるかを示しています。 ジェネリックのおかげで、Valueプロパティでの型変換を回避できます。 Changeオブジェクトは、プロパティを設定する最初の試みでこのコマンド内に作成されます。 T.O. パフォーマンスの低下は最小限に抑えられています。 ユーザーがコマンドを呼び出すと、各Changeオブジェクトに新しい値が入力されます。 フレームワークは、変更されたプロパティごとにOnCommitメソッドを自動的に呼び出します。



public class UndoRedo : IUndoRedoMember

{

//...



void IUndoRedoMember.OnCommit( object change)

{

((Change)change).NewState = tValue;

}

//...



}







上記で取得した古い値と新しい値は、フレームワークで元に戻す/やり直し操作を実行するために使用されます。 さらに、「パフォーマンス」セクションでは、これらすべてのアクションが非常に小さなパフォーマンスの低下を引き起こすことがわかります。 実際のアプリケーションでは、1％未満になる場合があります。

コレクション

前述したように、リストと辞書の変更は、単純なプロパティと同じ方法で適用/キャンセルできます。 これらの目的のために、ライブラリはUndoRedoList <>およびUndoRedoDictionary <>クラスを提供します。これらのクラスは、標準クラスのList <>およびDictionary <>と同じインターフェイスを持ちます。 ただし、この類似性にもかかわらず、これらのクラスの内部実装は、元に戻す/やり直し機能によって補完されます。 データオブジェクトがリストを宣言する方法を検討します。



class MyData

{

private readonly UndoRedoList myList= new UndoRedoList();



public UndoRedoList MyList

{

get { return myList; }

}

}







ここでは、リストがトランザクションをサポートしているが、リストへのリンクはサポートしていないというトリックがあります。 つまり、要素を追加、削除、並べ替えることができ、これらすべての変更を正しく元に戻すことができます。 ただし、リストへのリンクを別のリストへのリンクに変更することはできません。これは読み取り専用であるためです。



実際、私自身の経験から言えば、ほとんどの場合、クラスフィールドに格納されているリストは親データオブジェクトと同じ数だけ存在するため、これが問題を引き起こすことはありません。 別のデザインに慣れていて、リストへのリンクを変更したい場合は、少し注意が必要です。 以下に示すように、2つの汎用UndoRedo <>とUndoRedoList <>を組み合わせます。



private readonly UndoRedo<UndoRedoList> myList ...







辞書はリストと同じように使用できるため、繰り返しません。

障害保護

コードの実行がエラーにより中断される場合があります。 I / Oエラーまたは内部エラーは、エラーが適切に処理された場合でも、データの整合性を損なう可能性があります。 UndoRedoFrameworkはここで役立ち、データを元の状態に戻すことができます。 コードがエラーなしで実行されると、すべての変更が保存されます。 それ以外の場合、ロールバックが行われます。



try

{

UndoRedoManager.Start( "My Command" );

//



//...



UndoRedoManager.Commit();

}

catch (Exception)

{

UndoRedoManager.Cancel();

}







さらに、同じ成功を収めて、このコードのよりエレガントなレコードを使用できます。



using (UndoRedoManager.Start( "My Command" ))

{

//



//...



UndoRedoManager.Commit();

}







ご覧のとおり、最後の例では、失敗した変更のロールバックはありません。 これは、コードの実行がCommitメソッドの呼び出しに到達しない場合にロールバックが自動的に実行されるという事実により可能です。 エラーの場合。 この動作は、元に戻す/やり直し機能が必要ない場合でも、高度な信頼性を提供します。 エラーが発生すると、アプリケーションは回復し、動作状態を保存します。

UIとデータの同期

複雑なUIは、多くの場合、Model-View-Controllerパターンを使用して実装されます。 単純なWindowsアプリケーションでは、データ層とプレゼンテーション層のみがあります。 ただし、どちらの場合でも、開発者は特定のコードを作成してUIとデータを同期する必要があります。 デモプロジェクトには、3つのUIコントロールを持つメインフォームがあります。

• EditCityControl
• CitiesChartControl
• UndoRedoControlは、都市データに適用/キャンセルできるコマンドの2つのリストを表示します。

これらのコントロールは、都市の同じデータの異なる表現を示します。 実際のアプリケーション、つまり デザイナーまたはエディターは、多数のそのようなコントロールで構成されています。 データ同期の問題があります。1つのエンティティを変更するとビジネスロジックに従って他のエンティティを変更できるため、コントロールの1つがデータを変更した場合、すべてのコントロールがデータを更新する必要があります。



それで、何が必要ですか？ まず、同期を実行するコードは、コントロールまたはビジネスロジックのどこかで行われた変更を検出する必要があります。 次に、フォーム上のコントロールをリロードして、新しいデータを表示する必要があります。



この問題はさまざまな方法で解決できます-良い面と悪い面です。 私は、コードが首尾一貫しないように努力しています。 フォームはコンポーネントについて多くを知る必要はなく、コンポーネントはお互いについて知る必要もありません。 正直なところ、フォームに新しいコンポーネントを追加するたびに同期コードを書くのは面倒です。 この記事のデモプロジェクトをご覧ください。非常にシンプルなフォームが表示されます。



public partial class DemoForm : Form

{

public DemoForm()

{

InitializeComponent();



// init data



CitiesList cities = CitiesList.Load();

chartControl.SetData(cities);

editCityControl.SetData(cities);

}

}







フォームは、初期データをコントロールにロードするだけです。 したがって、フォームは同期しません。 コントロールイベントハンドラーも同期しません。たとえば、EditCityControlには「Remove City」ボタンイベントハンドラーがあります。



private void removeCity_Click( object sender, EventArgs e)

{

if (CurrentCity != null )

{

UndoRedoManager.Start( "Remove " + CurrentCity.Name);

cities.Remove(CurrentCity);

UndoRedoManager.Commit();

}

}







それにもかかわらず、データが変更されると、フォーム上のすべてのコントロールが更新されます。 これは、データが変更またはキャンセルされたときに発生する特別なフレームワークイベントによるものです。 これにより、すべてのUI更新コードを1か所で管理できます。



public EditCityControl()

{

//...



UndoRedoManager.CommandDone += delegate { ReloadData(); };

//...



}







したがって、CommandDoneイベントにサブスクライブするだけで、コントロールは多くの問題を解決します。 他のコンポーネントで変更が発生すると、コントロールは常に更新されたデータを表示します。 さらに、ユーザーが元に戻すまたはやり直し操作を実行すると、更新が実行されます。

性能

パフォーマンスと最適化は常に互いに競い合います...そしておそらく開発者のガールフレンドと自由時間のために競います。 この記事では、最初の2つの要因のみを検討します。 幸いなことに、エディターやデザイナーは、リアルタイムシステムとは異なり、ほとんどの操作に対して厳しいパフォーマンス要件を設定していません。 いくつかのケースについては、まだ短いパフォーマンス分析を行います。

• データを読み取っても、パフォーマンスが低下することはありません。 ジェネリックのおかげで、型変換とボックス化/ボックス化解除が回避されます。 値はすぐに返されます。その場合、変更履歴を検索する必要はありません。
• プロパティを変更しようとすると、内部ハッシュテーブルで単一の検索が行われます。 また、プロパティを最初に変更しようとすると、その値が変更履歴にコピーされます。
• リストを変更しようとすると、内部ハッシュテーブルで単一の検索が行われます。 さらに、初めてリストを変更しようとすると、フレームワークはリストのコピーを作成し、それをリスト変更履歴に書き込みます。
• 辞書を変更しようとすると、内部ハッシュテーブルで1回検索され、2つの小さなオブジェクトが作成されます。 フレームワークが辞書の完全なコピーを作成することはありません。 代わりに、変更を履歴に直接保存するだけです。
• 元に戻す方法とやり直し方法は、変更された値のみを復元します。 値を変更せずにアクションを実行することはありません。

つまり、パフォーマンスを大幅に低下させることなく、次のことができます。

• プロパティを読み取り、変更します。
• 中規模のリストを読んで変更します。
• 大規模な辞書を読んで適度に修正します。

ただし、複数の大きなリストを頻繁に変更すると、パフォーマンスが低下する場合があります。 この場合、データ設計を改訂し、大きなリストを部分に分割することをお勧めします。



以下に、実際のアプリケーションのパフォーマンステストデータを示します。 この例では、ユーザーはデザイナーでグラフィックオブジェクトのサイズを変更します。 平均的な操作では、5500回の読み取り、70個のプロパティの変更、4回の辞書の変更が実行されます。 元に戻す/やり直しに関連する余分な作業はすべて0.7ミリ秒未満です。 テスト結果は次のとおりです。

	呼び出し回数	合計ミリ秒	合計％
画像のサイズ変更と再描画		159.328	100％
元に戻す/やり直し操作の実行		0.677	0.425％
チームの初期化	1	0.008	0.005％
プロパティの読み取り	5461	0.114	0.071％
プロパティレコード	71	0.026	0.017％
辞書の変更	4	0.065	0.041％
チーム完成	1	0.463	0.291％

記憶

UndoRedoFrameworkは、変更を保存するためにのみメモリを使用します。 メモリ消費はデータの合計サイズに依存せず、変更されたデータの量にのみ依存します。 つまり 合計データサイズが数メガバイトであっても、変更履歴のサイズは数キロバイトになります。 ストーリーのサイズはデフォルトで制限されていませんが、静的プロパティUndoRedoManager.MaxHistorySizeを使用して制限できます。 このプロパティは、履歴に保存される操作の数を決定します。 指定した数の操作に達すると、古い操作は履歴から削除されます。



また、リンクとガベージコレクションに関連するいくつかのポイントについても説明します。フィールドに格納されているリンクは、別のリンクに置き換えることができます。 このオブジェクトへの他の参照がない場合、ガベージコレクターによる削除の候補になります。 以前の状態に戻りたいので、これは私たちには適していません。 幸いなことに、リンクは履歴に保存され、オブジェクトがデータモデルで使用されなくなっても、オブジェクトはガベージコレクタによって削除されません。



T.O. 古いオブジェクトは、対応する操作が履歴に保存されるまで削除の候補になりません。 これにより、データの整合性が保証されますが、メモリ使用量を評価する際にはこのことに留意する必要があります。

ジェネリックまたはプロキシ

元に戻す/やり直し機能を実装する別の方法は、プロキシを使用することです。 プロキシは、.NETの「呼び出しコンテキスト」機能を使用して、プロパティ呼び出しをインターセプトします。 このアプローチにより、変更に関する情報を保存し、その後変更をキャンセルできます。 このアプローチを実装した記事をこのサイトで見つけることができます。 これらはこの分野の専門家によって書かれた良い記事です。 次に、これらのアプローチの違いについて説明します。



プロキシとは、変更が何らかの「外部」方法で傍受されることを意味します。 プロパティによって実行される前に、セッタープロパティの呼び出しをインターセプトします。 変更の廃止も外部操作です。 プロパティの以前の値を復元するために、プロキシは適切と思われるプロパティのセッターを呼び出します。 この場合、さまざまな副作用が発生する可能性があります。プロパティの変更が他のプロパティに影響する場合はどうなりますか？ プロパティが通知イベントを生成した場合はどうなりますか？ このプロパティが、値がまだ復元されていない別のプロパティに関連付けられたビジネスロジックを使用する場合はどうなりますか？ したがって、「豊富な」プロパティを使用すると、元に戻す/やり直しが予期しない結果を招く可能性があります。



一方、ジェネリックは完全に機能します。 この手法は、プロパティとそのロジックに影響を与えることなく、変更をキャプチャして復元します。 変更を復元するプロセスは完全に目に見えません。 ビジネスルールと通知は複製されません。 したがって、変更のリカバリ中にデータの整合性が損なわれることはありません。

さらなる仕事

私は追加機能を開発し、プロトタイプを作成しています：

• データの変更が個別に保存される「分離された変更リポジトリ」の実装。 これは、ユーザーが各ドキュメントの変更を個別に変更/元に戻すことができるマルチドキュメントアプリケーションで使用できます。
• トランザクション内のファイルのサポート。 場合によっては、データ処理では、リソースファイルや単に一時ファイルなどの中間ファイルを使用する場合があります。 この場合、これらのファイルのバージョンはメモリ内のデータと互換性がなければならず、変更は元に戻すことができます。 フレームワークは、メモリ内のデータの変更とともにファイルへの変更を元に戻すことができます。
• 前の2つのタスクのマルチスレッドサポート。

このプロジェクトはCodePlexで公開されているため、誰でも使用したり貢献したりできます。