2

私は、膨大な数の操作（数十万）を実行するように設計されたフレームワーク風のコードに取り組んでいます。これらはすべて同じ基本コンポーネントを使用しますが、外部ソースから操作固有の構成データを受け入れる必要があります。

今のところ、設定名の適切なリストがあれば、これらの設定を効率的にロードして次のようなタイプで保存する方法を知っている構成リポジトリーがあると想定します。

public interface IConfiguration
{
    dynamic Get(string key);
    void Set(string key, dynamic value);
}

私が計画しているのは、流暢なマッピング構文を実装するか、コンポーネントクラスを次のような属性で装飾することです。

public class MyComponent : IActivity
{
    [Configuration("Threshold")]
    public virtual int Threshold { get; set; }

    [Configuration("SomeKey", Persistence = ConfigPersistence.Save)]
    public virtual string SomeSetting { get; set; }
}

あなたは写真を手に入れます...うまくいけば。注意すべき重要な点は、一部のプロパティは実際にリポジトリに保存する必要があるため、従来のDIライブラリはここでは機能しないということです。たとえそうだったとしても、それらは数十万のコンポーネントを回転させ、数百万の属性をロード/保存するように設計されていない鈍器です。言い換えれば、私は車輪の再発明をしているとは思いませんが、誰かが私を説得しようとするなら、遠慮なくしてください。

とにかく、これらのコンポーネントインスタンスへの構成データの「注入」を処理するための2つの可能なオプションを検討しています。

  1. プレーンバニラリフレクション-タイプをスキャンして構成属性を探し、メンバー情報を（構成キーとともに）静的ディクショナリに保存します。PropertyInfo.SetValue次に、注入やPropertyInfo.GetValue抽出などの反射方法を使用します（より適切な用語がないため）。これは、ほとんどのDIライブラリで使用されているアプローチに似ています。

  2. Castleなどの動的プロキシを使用し、装飾されたプロパティにインターセプターを接続して、プライベート/自動生成フィールドを参照する代わりに、IConfigurationインスタンス（つまり、getメソッド呼び出しIConfiguration.Getとsetメソッド呼び出しIConfiguration.Set）を参照するようにします。これは、NHibernateや他のORMで使用されているアプローチに似ています。

完全な実装はかなりの量の作業になる可能性があるので、何かを逃したことに気付く前に、間違った道を行き過ぎたくありません。

だから私の質問は、どちらのアプローチの長所/短所は何ですか、そして私が避ける必要がある落とし穴は何ですか？ パフォーマンス、保守性、フールプルーフなどの広い視野で考えています。

または、代わりに、この目標へのより迅速なパスが他にありますか？できれば、急な学習曲線がないものがありますか？

4

1 に答える 1

0

動的プロキシは、はるかに優れたアプローチです。構成からコンポーネントに値を注入する「構成」インターセプターを定義します (できれば遅延)。動的プロキシを使用して、プロキシされたコンポーネントに汎用の IDisposable インターフェイスも実装します。これにより、オブジェクトが破棄または GC されたときに、属性に設定された Peristence フラグに基づいて構成値が保持されます。

于 2012-01-20T21:25:05.783 に答える