使用嵌套的 ILifetimeScope 解析服務 Autofac 被設計為跟蹤(track)和清理(dispose)資源。為確保資源被正確處理，務必將長時間運行的應用程式分成小的工作單元 (請求或事務)，服務的解析應在工作單元級別的生命周期範圍中進行。為 asp.net 實現的每個請求一個生命周期 ...
使用嵌套的 ILifetimeScope 解析服務
Autofac 被設計為跟蹤(track)和清理(dispose)資源。為確保資源被正確處理，務必將長時間運行的應用程式分成小的工作單元 (請求或事務)，服務的解析應在工作單元級別的生命周期範圍中進行。為 asp.net 實現的每個請求一個生命周期範圍 是這項技術的一個示例。
使用模塊進行配置
Autofac 模塊(module) 提供了一種組織容器配置的方式，並允許註入“部署時設置”。與 XML 配置相比，模塊是更有彈性的方式。模塊可以隨時組合到 XML 配置中，提供兩全其美的體驗。
在委托註冊中使用 As<T>() 方法
Autofac 從註冊組件的表達式推斷實現類的類型:
builder.Register(c => new Component()).As<IComponent>();
上面的代碼中，組件的 LimitType 是 Component 類。以下兩種類型轉換的方式是等價的，但是未提供正確的 LimitType：
// 行的通，但應避免這種寫法 builder.Register(c => (IComponent)new Component()); //行的通，但應避免這種寫法 builder.Register<IComponent>(c => new Component());
使用構造函數註入
使用構造函數註入必需的依賴，使用屬性註入可選的依賴，這個概念廣為人知。但是，作為替代，也可以使用“空對象模式” 或 “特例模式” 為可選服務提供預設的，什麼都不做的實現。這樣可以減少組件實現中處理特殊情況的分支(比如 if (Logger != null) Logger.Log("message");).
使用關聯類型，而不是服務定位器
將容器存在公共靜態屬性中，以便組件可以訪問到容器，或在全局的“Ioc”類中提供諸如 Resolve() 之類的函數，這些做法會使依賴註入的意圖落空。這樣的設計實際上是服務定位器器模式。
如果組件有對容器(或生命周期範圍)的依賴，請查看組件是如何使用容器獲取服務的，然後將服務通過構造函數註入到容器中。
如果組件需要實例化其他組件，那麼請為它使用關聯類型 ，或者用更高級的方式同容器交互。
按照不特定到特定的次序註冊組件
Autofac會覆蓋組件註冊。應用程式可以註冊所有預設組件，然後讀取配置文件，用定製的組件覆蓋預設的版本。
使用 Profilers 檢查性能
如果要進行優化，或懷疑記憶體泄漏，請首先使用profiler 工具（比如SlimTune, dotTrace, 或 ANTS）檢查，確定程式時間到底消耗在哪裡。很可能與設想的不同。
一次註冊，多次解析
如有可能，請勿在工作單元執行過程中註冊組件。註冊組件的代價要遠大於解析組件。使用生命周期範圍和適當的實例範圍使工作單元彼此隔離。
使用拉姆達表達式註冊頻繁使用的組件
如果確實需要榨取額外性能，最好的辦法是標記出解析最頻繁的組件，並使用拉姆達表達式註冊代替類型註冊：
builder.RegisterType<Component>();
改為:
builder.Register(c => new Component());
這可以讓 Resolve 方法速度提高 10 倍，但是僅對出現在很多對象圖中的組件有意義。請參考Aufofac中註冊的概念。
