オブジェクト指向のGin Installer開発

はじめに

次の一連の記事には、いくつかの主要な目標があります。

1. 有用なソフトウェアを作成する-プログラムと更新プログラムのインストーラー。
2. ソフトウェア開発に対するオブジェクト指向アプローチの利点を示し、簡単に拡張可能なソフトウェアアーキテクチャを作成する方法を教えます。

この一連の記事では、パッケージを使用して会社のソフトウェア製品をインストールおよび更新できるソフトウェア作成の歴史を共有したいと思います。 （既製のソリューションの使用を拒否して）独自のインストーラーを作成する必要があるのは、インストーラーの要件の特異性が原因です。 一連の記事のトピックが異なるため、開発の必要性の理論的根拠を掘り下げません。
開発中のアーキテクチャの主な要件は次のとおりです。

1. トランザクションメカニズムの実装、およびトランザクションには、SQLトランザクションだけでなく、ファイルトランザクションだけでなく、レジストリエントリ、構成ファイルの変更など、他のOSリソースの変更に関連するトランザクションも含まれます。
2. インストーラーの操作ベースの拡張性、つまり、トランザクションサポートの有無にかかわらず、新しいタイプのコマンド（操作）の追加。

したがって、最初の近似の各パッケージには以下が含まれている必要があります。

1. 実行されたコマンドのシーケンスの説明。
2. データファイルの任意のセット。

.NETプラットフォームには、オブジェクトをXMLファイルにシリアライズ/デシリアライズするための便利でシンプルなクラスが含まれているため、コマンドのシーケンスの説明をXMLファイルに保存します。これにより、操作を詳しく調べることなく、アプリケーションのメインロジックに集中することができます。行で。
パッケージ自体はTARアーカイブの形式で、場合によってはGZIP圧縮の対象となることもありますが、パッケージの保存方法（その構造と圧縮方法）を変更することを決定するときに、既存のコードへの最小限の介入が必要になるようにソフトウェアを設計しようとします。
将来のソフトウェアのコマンドセットを推定しましょう。

1. ファイル操作
2. SQL操作
3. IISサーバー管理
4. 多分何か...

前述したように、コマンドのセットは拡張できます。 さらに、主な機能（ソフトウェアコア）が別のアセンブリに保存され、実行される可能性のあるコマンドが、プラグインの概念を使用してメインモジュールに接続された別のアセンブリに設定されるようにします。
ソフトウェア開発プロセス中に解決する必要がある興味深いタスクの数から、すでに息を引き取っています。 これらの行を書いている時点で、アプリケーションの実際のプロトタイプが既にあり、実際にはまだ宣言されたすべての機能を備えていないため、変更を加えることは私が望むよりも少し難しいことをすぐに予約します。 それで、私はまだそれをリファクタリングします。 ファイル操作用のトランザクションを作成する機能は既にありますが、単一のトランザクション内でファイル操作とSQL操作を組み合わせる方法はわかりません。 プラグインのサポートはまだ実装されていません。 コマンドセットに新しいコマンドを追加すると、4つのファイルを編集する必要があります。必要なのは、新しいクラスを宣言するだけです。 一般的に、仕事は耕されていない畑です。
最初の近似では、システムのクラス図は次のようになります。

これには、アプリケーションが実行できるすべての操作（コマンド）の親クラスと、そこから継承されたいくつかのコマンド（CreateFileCommandおよびDeleteFolderCommand）があり、最終的には多くなります。 また、一連のコマンドを含むPackageBuilderクラスもあります。 PackageBuilderは、パッケージを作成してユーザーに提供できます。 パッケージは保存して実行できます。
その結果、これらのクラスを使用する擬似コードは次のようになります。

void CreatePackage() { //     PackageBuilder builder = new PackageBuilder(); builder.AddCommand(new CreateFolderCommand() { FolderPath = @"%APPROOT%\files" }); builder.AddCommand(new CreateFileCommand() { SourcePath = @"d:\package\config.xml", //      DestPath = @"%APPROOT%\files\config.xml" //     }); Package package = builder.GetResult(); package.SaveAs(@"d:\package\output\package.pkg"); } void ExecutePackage () { //    Package package = new Package(@"d:\package\output\package.pkg"); package.Execute(); } 

もちろん、クラスの構造にはまだ多くの変容を起こす時間がありますが、どこかから始めなければなりません。

基本的なコマンドシステム

インストーラーコマンドの基本的なシステムを理解してみましょう。 ここでは、ユーザーが機能を簡単に拡張できるようにするため、インストーラーのすべての機能をリストするつもりはありません。
ここでは、残りのチームを結合できる基本的なワイヤーフレームコマンドについて説明します。 すべてのコマンドが継承される抽象クラスには、単一のDo（）メソッドが含まれます。このメソッドは、コマンドによってプログラムされたアクションを実際に実行します。 たとえば、DeleteFileコマンドは、このDo（）メソッド内に正確にファイルを作成し、パブリックプロパティ文字列FilePathを引数（削除されたファイルのパス）として使用します。 これがどのように見えるかです：

 public abstract class Command { public abstract void Do(); } public class DeleteFile: Command { public string FilePath { get; set; } public override void Do() { File.Delete(FilePath); } } 

他のすべてのコマンドはまったく同じ方法で実装されます。コマンドは抽象クラスCommandを継承し、継承されたクラスのパブリックプロパティを引数として使用してDo（）メソッドを置き換えます。
したがって、最初の近似では、PackageBuilderでチームが次々に追加されると想定しましたが、このアプローチの柔軟性のなさをすぐに実感しました。 インストーラコマンドのシーケンスが、ターゲットマシンにインストールされているサードパーティソフトウェアのバージョン番号に依存する必要があるとします。 たとえば、サイトのインストールアルゴリズムは、ターゲットマシンにインストールされているIISのバージョンに大きく依存しています。 または、たとえば、インストーラーはターゲットマシンに必要なCOMオブジェクトが存在するかどうかを確認し、必要に応じてそれらをインストールする必要があります。 これらのすべての場合において、いくつかのレジストリ値をチェックし、そこから読み取られた値に応じてさらにアクションを選択する必要があります。 ここから、ベースセットに条件付き実行コマンドが必要になりました。それをExecuteIfと呼びましょう。 インターフェイスの説明は次のとおりです。

 public class ExecuteIf : Command { public string ArgumentName { get; set; } public Command Then { get; set; } public Command Else { get; set; } public void Do(); } 

つまり、Do（）メソッドは、ある実行コンテキストからArgumentNameというブール変数を読み取り、Trueの場合はThenコマンドを実行し、そうでない場合はElseコマンドを実行します。 ここで、私たちは新しい概念に直面しています-実行のコンテキスト。 実行コンテキストをExecutionContextクラスのインスタンスとします。このインスタンスは、各コマンドのDo（）メソッドの呼び出しの引数になります。 オーバーロードされたDo（ExecutionContext）メソッドで抽象クラスインターフェイスを膨らまさないために、Do（）メソッドは常にExecutionContext引数で呼び出されることに同意しますが、実行コンテキストを変更しないコマンドは、Do（）メソッド引数を単に無視します。

したがって、クラスは次のようになります。

 public abstract class Command { public abstract void Do(ExecutionContext context); } public class DeleteFile: Command { public string FilePath { get; set; } public override void Do(ExecutionContext context) { File.Delete(FilePath); } } public class ExecuteIf : Command { public string ArgumentName { get; set; } public Command Then { get; set; } public Command Else { get; set; } public void Do(ExecutionContext context); } 

コマンドの基本セットの説明から注意をそらし、クラスExecutionContextを設計します。

実行コンテキスト

パッケージ内で実行された各チームは、有用な作業を実行することに加えて、実行結果を返すこともできます。 たとえば、SQLコマンドは、ストアドプロシージャの実行結果または変更された行数を返すことができ、レジストリから読み取ると、読み取った実際の値が返されます。 さらに、一般的な場合、コマンドは1つのValueType結果ではなく、複数を返すことができます。たとえば、DataSetなどの複雑な結果を返すこともできます。 他のチームが以前の操作の結果に依存して正しく動作するためには、以前のコマンドの結果にアクセスする方法をチームに提供する必要があります。 同時に、各特定のコマンドは、厳密に前のコマンドの実行結果だけでなく、一般に、以前に実行されたコマンドも含めて、以前のいくつかのコマンドの実行結果に一度に依存できます。 たとえば、SqlQueryCommandコマンドによって以前に返された文字列の配列内の（ユーザーが入力した）行のインデックスを定義するFindIndexCommandコマンドを作成できます。 ご覧のとおり、この場合のFindIndexCommandコマンドの結果は、SqlQueryCommandコマンドによって返されたDataSetと、UserInputCommandコマンドを使用してユーザーが入力した文字列の2つの引数に基づいています。 私はまだ設計さえしていないチームの名前で業務を行っており、チームの名前からその目的が明確であることを暗示しています。
ユーザーにそのような柔軟性を与えるために、実行コンテキストExecutionContextを導入する予定です。 特定のキーの下に値を格納し、値がある場合はそこから値を読み取ることができます。 実行された各コマンドは、Do（）メソッドの最初の引数として受け取ります。 したがって、各チームは、以前に実行されたすべてのチームの結果にアクセスできます。
ExecutionContextクラスは次のようになります。

 public class ExecutionContext { private Dictionary<string, object> _results = new Dictionary<string, object>(); public void SaveResult(string key, object value) { _results[key] = value; } public object GetResult(string key) { return _results[key]; } } 

おそらく将来、他のメソッドが追加されるかもしれませんが、今のところは上記のリストのような単純な形式になります。
最初は、次のようなExecutionContextを使用していました。

 public class DeleteFile: Command { public string FilePath { get; set; } private ExecutionContext _context; public DeleteFile(ExecutionContext context) { _context = context; } public DeleteFile() { } public override void Do() { } } 

つまり、インスタンスを引数としてコマンドコンストラクターに送信し、プライベート変数に保存してから、必要に応じてDo（）メソッドで使用します。 ただし、コマンドパッケージは通常、最初にシリアル化されて保存され、次に結果ファイルがデシリアライズされて実行されることを思い出しました。この2番目のステップでは、デシリアライザーがパッケージをメモリに自動的に復元しますが、閉じた変数_contextが初期化されません（閉じているため）パッケージは初期化されていないコンテキストで実行されます。 コンテキストはダウンロードしたパッケージの実行段階でのみ必要であると考え、コンテキストをDo（）メソッドの引数として送信することにしました。 これはすぐに別の利点をもたらしました-新しいコマンドごとにこの繰り返しコードを記述する必要がなくなりました。

 private ExecutionContext _context; public DeleteFile(ExecutionContext context) { _context = context; } public DeleteFile () { } 

結局、引数を持つコンストラクターは不要になりました。つまり、コンパイラーがデフォルトのコンストラクターを作成するため、デフォルトのコンストラクターを記述する必要もありません。 これで、コマンドフレームワークは次のようになります。

 public class DeleteFile: Command { public string FilePath { get; set; } public override void Do(ExecutionContext context) { } } 

つまり、その中に余分なものはなく、本質だけがあります。 これは、アプリケーションをサポートおよび開発するプログラマーがその本質を理解しやすくなることを意味します。
これで、ExecuteIfコマンドの実装を記述できます。

 public class ExecuteIf : Command { public string ArgumentName { get; set; } public Command Then { get; set; } public Command Else { get; set; } public override void Do(ExecutionContext context) { if ((bool)context.GetResult(ArgumentName)) { Then.Do(context); } else if (Else != null) { Else.Do(context); } } } 

基本的なコマンドシステム。

インストーラーコマンドフレームワークの作成に戻りましょう。 基本抽象クラスCommand、および条件付きコマンドExecuteIfについては既に説明しました。 ExecuteIfコマンドのThenおよびElseパラメーターには、1つのコマンドだけでなく、連続したコマンドのブロック全体を指定できます。 そして、これはコマンドを設計する必要があることを意味します-演算子括弧の類似物。 このコマンドをCommandSequenceと呼びます。 そのインターフェースと実装は簡単です：

 public class CommandSequence : Command { public List Commands; public override void Do(ExecutionContext context) { foreach (Command command in Commands) { command.Do(context); } } } 

その唯一のパラメーターはコマンドのリストであり、Do（）メソッドは単純にそれらを順番に実行します。

ExecuteIfコマンドは、入力コンテキストとして実行コンテキストからブール変数の名前を受け入れることを思い出してください。 このブール変数は、コンテキストのどこかに表示されるはずです。 彼女は特定の状態をチェックした結果、そこに現れるはずです。 そして、量を比較するためのチームを設計する時が来ました。 文字列比較コマンドを開始するように設計します。 コマンドインターフェイスとその部分的な実装は次のようになります。

 public class CompareStringsCommand: Command { public string FirstOperandName { get; set; } public string SecondOperandName { get; set; } public string ResultName { get; set; } public void Do(ExecutionContext context) { string operand1 = (string)(context.GetResult(FirstOperandName)); string operand2 = (string)(context.GetResult(SecondOperandName)); bool result = Compare(operand1, operand2); context.SaveResult(ResultName, result); } } 

コマンドは、コンテキストから2つの変数をFirstOperandNameとSecondOperandNameの名前で読み取り、それらを比較し（Compare（）メソッドを使用して比較を指定します）、比較のブール結果をResultNameという名前でコンテキストに保存します。
このコマンドは、他のすべての文字列比較コマンドの基本抽象クラスになるための優れた候補であり、Compare（string、string）メソッドは、抽象クラスメソッドになり、継承者に実装するための優れた候補であることがわかります。 次に、抽象クラスのインターフェースのみを書き直し（Do（）メソッドの実装は同じまま）、相続人の1人のコードも提供します。

 public abstract class CompareStringsCommand: Command { public string FirstOperandName { get; set; } public string SecondOperandName { get; set; } public string ResultName { get; set; } protected abstract bool Compare(string operand1, string operand2); public override void Do(ExecutionContext context) { //    ,       } } public class StringStartsWith : CompareStringsCommand { protected override bool Compare(string operand1, string operand2) { return operand1.StartsWith(operand2); } } 

ご覧のとおり、バイナリ（2つの引数）比較演算子のコマンドセットは、CompareStringsCommandクラスの継承者を作成し、その中にCompare（string、string）メソッドを定義するだけで、他の比較操作（EndsWith、Contains、Equals、NotEquals）で簡単に拡張できます。
この段階での単項演算（たとえば、IsNullOrEmptyなど）は、第2オペランドを単に無視して、同じ基本クラスを使用して実装することを提案します。
これに注意しましょう。 CompareStringsCommandコマンドは、実行コンテキストに格納されている2つの引数を比較します。これらの引数は、他のコマンドの結果としてのみ存在します。 しかし、たとえば、レジ​​ストリから読み取られた行が一定の部分文字列で始まるかどうかを知りたい場合はどうすればよいですか？ この定数が実行コンテキストに存在することを確認する必要があります。 指定された名前で実行コンテキストに値を単純に保存するコマンドを設計します。 ここではすべてが簡単です：

 public class SaveConstantCommand: Command { public string ResultName { get; set; } public object Value { get; set; } public override void Do(ExecutionContext context) { context.SaveResult(ResultName, Value); } } 

次の章では、トランザクションメカニズムの実装について説明します。

第二部へのリンク