基於反射的注入與動態代理：實際考慮？

我正在研究一些設計用於執行大量操作（數十萬）的framework-ish代碼，所有這些代碼都使用相同的基本組件，但需要接受來自外部源的特定於操作的配置數據。基於反射的注入與動態代理：實際考慮？

承擔的那一刻，有一個配置庫其中，由於設置名稱的相應列表，知道如何有效地加載這些設置並在類型存儲這樣的：

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庫不在此處工作;即使他們這樣做了，它們也不是用於旋轉數十萬個組件並加載/保存數百萬個屬性的鈍器。換句話說，我不認爲我在重塑車輪，但如果有人想試圖說服我，否則，感覺自由。

不管怎樣，我正在考慮兩個可能的選項，以處理配置數據的「注入」到這些組件實例：

普通的香草反思 - 掃描配置屬性的類型和保存成員信息（以及配置鍵）在一個靜態字典中。然後使用反射方法，例如PropertyInfo.SetValue和PropertyInfo.GetValue進行注射和提取（因爲缺少更好的術語）。這與大多數DI庫使用的方法類似。
使用如城堡的動態代理這樣和掛鉤攔截的裝飾性能，例如，代替參考私人/自動生成的字段，它們引用IConfiguration實例（即get方法調用IConfiguration.Get和set方法調用IConfiguration.Set ）。這與NHibernate和其他ORM使用的方法類似。

全面實施可能最終會被工作了相當多的，所以我不想去太遠了錯誤的道路實現我錯過了什麼之前。

所以我的問題是，什麼是這兩種方法的優點/缺點，什麼是我需要避免重蹈覆轍？我在廣泛的性能，可維護性，防白癡等方面的想法。

或者，或者，還有其他更快的路徑來實現這一目標，最好是沒有陡峭的學習曲線？

來源

2011-05-05 Aaronaught

嗯，這是我的一個老問題，我沒有時間寫一個完整的答案，但對於任何其他人誰在這方面絆倒：我最終使用反射的初始掃描，然後編譯/緩存使用表達式樹建立的代表。我知道它不如IL編織速度快，但它是對直線反射的重大改進，對於這裏的要求足夠快。 – Aaronaught 2012-01-20 21:56:43

動態代理是更好的方法。定義一個「配置」攔截器，將配置中的值注入組件（最好是懶惰地）。使用動態代理，我也想實現一個通用IDisposable接口到你的代理組件，因此當對象被處置，或者GC'd，其將根據Peristence標誌在你的屬性設置堅持配置值。

來源

2012-01-20 21:25:05 Ravi

基於反射的注入與動態代理：實際考慮？

回答

相關問題