Unity 方法調用注入實戰：靈活初始化的另類選擇

何時選擇 Method Call Injection？

• 構造函數過多、參數相近導致調試維護困難
• 需隱藏依賴細節，不暴露為公共屬性
• 希望通過修改依賴實現類控制注入行為，而不動父類代碼
• 初始化邏輯複雜，需在對象構造後執行特定方法

核心機制：[InjectionMethod] 標記延遲執行

不同於構造函數注入（解析即執行），方法注入在對象創建後、返回調用者前由容器自動調用標記方法，並自動解析其參數依賴。

實戰範例：播放器初始化歌曲

public interface IPlayer { void Play(); }
public class Song {
    public string Name => "My Love";
    public string Singer => "Westlife";
}
public class Mp3Player : IPlayer {
    public Song CurrentSong { get; private set; }
    [InjectionMethod]
    public void Initialize(Song song) => CurrentSong = song; // 容器自動調用並注入 Song
    public void Play() => Console.WriteLine($"{Name}: Now Playing [{CurrentSong.Name}] by ({CurrentSong.Singer})");
    public string Name => "Mp3 Player";
}

容器配置與解析

var container = new UnityContainer();
container.RegisterType<IPlayer, Mp3Player>(); // Song 類無需顯式註冊，容器自動實例化具體類
var player = container.Resolve<IPlayer>();
player.Play(); // 輸出: Mp3 Player: Now Playing [My Love] by (Westlife)

關鍵行為細節

1. 參數自動解析：方法參數類型需在容器中可解析（已註冊或為具體類）
2. 單一方法限制：每類型僅允許一個 [InjectionMethod]，多標記將拋異常
3. 執行時機：Resolve 過程中，構造函數完成後、屬性注入前/後（具體順序視版本）調用
4. 現有實例不適用：Resolve 獲取現有實例不觸發方法注入，需用 BuildUp（但 BuildUp 也不調用構造函數）

循環引用風險預警

方法間相互調用（Method1→Method2→Method1）將導致死循環，參考《Unity 循環引用四大場景》規避。

對比總結：三種注入方式的定位

官方建議：無特殊理由優先選構造函數注入，它最符合通用需求且最安全。