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

最初の部分へのリンク

第二部へのリンク

第三部へのリンク

データ入力

インストーラーは、いくつかの開始パラメーター、たとえばプログラムがインストールされるフォルダーへのパス、データベースへの接続文字列などを入力する機能をユーザーに提供する必要があります。 さらに、テキストフィールドだけでなく、便利なデータウォーターを可能にするフィールドにしたいと思います。 これがプログラムのインストールパスである場合、テキストフィールドに加えて「Browse ...」ボタンが必要です。データベースへの接続文字列である場合は、データソースを選択または作成するためのボタンを横に置きます。



入力フォームをコマンドとして実装します。

public class UserInputCommand: Command { public List<UserInputControl> InputControls { get; set; } public string FormCaption { get; set; } public override void Do(ExecutionContext context) { foreach (UserInputControl input in InputControls) { Control control = input.Create(); //       context.InputForm.Controls.Add(control); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

InputControlプロパティを実行コンテキストに追加しました（どこで初期化するかまだわかりません）。これは、ユーザーコントロールを追加するコンテナーコントロールです。

UserInputControlクラスは、Create抽象メソッドでも表示されます。

 public abstract class UserInputControl { public string ResultName { get; set; } public int Height { get; set; } public abstract Control Create(); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは、たとえばUserInputTextBox-単純なテキスト入力フィールドなど、特定のすべてのユーザーコントロールを継承する抽象クラスです。

 public class UserInputTextBox : UserInputControl { public string Caption { get; set; } public string InitialValue { get; set; } public override Control Create() { TextBox textbox = new TextBox(); return control; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これは単純化されたコードです。 実際、テキスト入力フィールドに加えて、キャプションヘッダーを表示するラベルもあり、これらの2つのコントロールはパネルに配置され、Createメソッドの結果として実際に返されます。 この例に基づいて、UserInputControlから継承して、他のすべてのユーザーコントロールを作成します。

さらに、入力フォームはユーザー入力の終了を待つ必要があります。これは、[次へ]ボタンのクリックを続けて、別のストリームでメインインストーラー制御フローを起動することで実装しました。

連載

NETプラットフォームで十分にサポートされているため、XMLシリアル化形式を選択しました。 System.Xml.Serialization.XmlSerializerクラスを使用します。使いやすいため、オブジェクトをシリアル化するのに必要なコードは3行だけで、System.Xml.Serialization名前空間の属性を使用することで柔軟性が向上します（必要な場合） 。

このコードは次のとおりです。

 //  XmlSerializer ser = new XmlSerializer(typeof(T)); FileStream stream = new FileStream(filePath, FileMode.OpenOrCreate, FileAccess.Write); ser.Serialize(stream, obj); // XmlSerializer ser = new XmlSerializer(typeof(T)); stream = new FileStream(filePath, FileMode.Open, FileAccess.Read); result = (T)ser.Deserialize(stream);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ご覧のとおり、以下は入力引数です。シリアル化されたオブジェクトが書き込まれるファイルへのパス。 オブジェクト自体。 シリアル化可能なオブジェクトのタイプ。 このコードは、他のクラスから継承されないシリアル化に最適です。 ただし、たとえば、継承階層がCreateFile <-TransactionalCommand <-CommandであるCreateFileクラスをシリアル化する場合、T = Commandで、シリアライザーは、XmlInclude属性を使用する必要があることを通知します。シリアライズ可能なオブジェクト。 そして、これらの属性を基本クラスCommandに適用する必要がなく、可能なすべての子孫に1つの属性XmlIncludeを指定する場合、これはそれほど問題になりません。 そして、ユーザーはCommandクラスのソースコードにアクセスせずにプラグインの形でコマンドのコレクションを増やすと想定しているので、これはシリアライザーがユーザーによって追加されたこれらすべてのクラスをシリアル化できないことを意味します。 幸いなことに、解決策があります。 すべての組み込み型は、属性だけでなく、XmlSerializerコンストラクターの直接の引数でも設定できます。2番目の引数には、Type []組み込み型の配列を指定できます。

 Type[] types; XmlSerializer ser = new XmlSerializer(typeof(T), types);
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そしてこれは、シリアライザーのインスタンスを作成するときに、使用されるすべてのタイプに関する情報が必要であることを意味します。 つまり、インストーラーに関するメタ情報。

プラグインとメタデータ

このためのGinMetaDataクラスを紹介します

 public class GinMetaData { public List<ExternalCommand> Commands { get; private set; } public Type[] IncludedTypes { get; private set; } public static GinMetaData GetInstance(); public void Plugin(string folderPath) public ExternalCommand GetCommandByName(string name) }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

アプリケーションには、常にこのクラスのインスタンスが1つだけあると考えられます。つまり、シングルトンとして実装することを意味します。 この場合、IncludedTypesプロパティには、シリアライザーで使用できるすべてのタイプ、およびメインインストーラーライブラリとそのすべてのプラグインの両方のタイプが含まれます。 新しいプラグインをメタデータに接続するには、プラグインフォルダーへのパスを入力として使用するPluginメソッドが使用されます。 異なるフォルダに対して複数を呼び出すと、すべてのNETライブラリがプラグインの形式でアプリケーションに接続されます（もちろん、新しいコマンドと補助クラスが含まれている場合を除きます）。

インストーラーで使用可能なすべてのコマンドへのリンクは、GinMetaData.Commandsリストにロードされます。 これを行うために、GinMetaDataクラスにLoadCommandsFrom（Assembly）メソッドを作成しました。

 private void LoadCommandsFrom(Assembly assembly) { foreach (Type type in assembly.GetTypes()) { if (ExternalCommand.ContainsCommand(type)) { ExternalCommand cmd = new ExternalCommand(type); Commands.Add(cmd); _includedTypes.Add(cmd.CommandType); } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このコードで使用されるExternalCommandクラスを考慮するだけです。 インターフェイスは次のとおりです。

 public class ExternalCommand { public ExternalCommand(Type type) public Type CommandType { get; private set; } public Command Instance { get; private set; } public PropertyInfo[] Properties { get; private set; } public ConstructorInfo Constructor { get; private set; } public CommandMetadata Metadata { get; private set; } public static bool ContainsCommand(Type type) public object GetProperty(string propertyName) public void SetProperty(string propertyName, object value) public ExternalCommand Clone() }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ExternalCommandの各インスタンスは、本質的にはCommandクラスの子孫である各クラスのインスタンスのラッパーです。 ExternalCommandクラスには、Type型の引数を持つ1つのコンストラクターがあります-NETアセンブリからロードされた型です。 一般的なプラグインアセンブリでは、コマンドだけでなく補助クラスも存在する可能性があるため、アセンブリから読み込まれた型からCommandのインスタンスを作成する前に、読み込まれた型が有効なコマンドかどうかを確認する必要があります。 静的メソッドContainsCommand（Type）は、ロードされた型がすべての正式な要件に準拠しているかどうかをチェックするだけです-型はCommandまたはその子孫から継承される必要があり、型は抽象であってはなりませんそのタイプはGinIgnoreType属性でマークされるべきではありません（プラグイン開発者がプラグインからインストーラーにエクスポートされるべきでないタイプをマークできるようにするために特に属性を導入しました）。

CommandTypeプロパティには、ロードされたコマンドのリフレクションのTypeオブジェクトが格納され、Instanceプロパティには、Constructorコンストラクターを使用して作成されたロードされたコマンドのインスタンスが格納されます。 Propertiesプロパティは、コマンドプロパティの配列を提供します。 コマンドインスタンスは、コマンドへの参照としてExternalCommandに格納されているため、すべてのコマンドの親クラスであり、そのインターフェイスにはDo（）メソッドのみがあり、このインスタンスのプロパティは直接利用できないため、すべてのプロパティを直接エクスポートしました配列PropertyInfo。 しかし、このプロパティは主にプロパティのリストにのみ必要です。 特定の各プロパティを設定および読み取るために、ExternalCommandクラスには、GetProperty（文字列キー）とSetProperty（文字列キー、オブジェクト値）の2つのメソッドがあります。

メタデータプロパティは、読み込まれたコマンドに関するメタデータです。 このメタデータを使用して、ビジュアルパッケージデザイナーのインターフェイスにコマンドを表示することを意味しました。 この記事の主題ではありませんが、その存在を暗示する必要があります。 コマンドのメタデータには、コマンドのパラメーターを名前、説明、パッケージデザイナーでの表示方法などとして保存できます。 現時点では、チームのメタデータには、チームの名前、説明、およびチームグループの名前の2つのパラメーターのみが含まれています。

 public class CommandMetadata { public string Name { get; set; } public string Desription { get; set; } public string Group { get; set; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コマンドのグループ。これはテキスト文字列です。パッケージデザイナーのインターフェイスにあるコマンドのグループ化ノードの名前です。 リスト内の多数のコマンドをグループごとに構造化する必要があります。たとえば、ファイル操作、IIS管理、SQLコマンド、構造化コマンドなどです。 そして他のグループ。

メタデータは、属性を使用してチームに添付されます。 これまでのところ、GinNameAttributeコマンドのメタデータ属性は1つしかありません。その説明を次に示します。

 [AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = true)] public class GinNameAttribute : Attribute { public string Name { get; set; } public string Description { get; set; } public string Group { get; set; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

たとえば、次のようにコマンドクラスに適用されます。

 [GinName( Name = "-", Description = "  if-then-else", Group = " ")] public class ExecuteIf : TransactionalCommand, IContainerCommand { // …… }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

各コマンドがExternalCommandインスタンスに読み込まれると、その属性もコマンドから読み取られます。これには、GinNameAttribute属性が含まれます。その後、この属性はCommandMetadataクラスのインスタンスに変換されます。

インストーラーのソースコードと、その使用に関する3つの典型的なシナリオ（パッケージの作成、実行、およびロールバック）を、 google-codeのリポジトリーに投稿しました。 独自の目的に使用できます。 これは、インストーラーの設計に関する最後の投稿だと思います。