在許多應用程式中，指定的類需要使用元件對象。IoC模式允許父對象（在WebWork中是XWork的ComponentManager執行個體）給與Action對象它所需要的資源對象，而不是該對象需要自己去獲得資源對象。
有兩種方法實作IoC：執行個體化和使用enabler接口。
l 執行個體化：在Action對象執行個體化時，将資源對象作為構造函數參數傳遞。
l 使用enabler接口：XWork使用enablers傳遞元件對象。Action實作enabler接口，帶有叫做setComponent(ComponentObject r)的方法。這樣，在該對象執行個體化時，資源對象就會傳遞給該對象。
為什麼使用IoC？
使用IoC意味着你可以自上而下的方式開發元件，不需要建立客戶程式需要調用的注冊類，并自己去獲得元件執行個體。
傳統方式實作服務，大概下面有類似的步驟：
l 編寫元件（例如ExchangeRateService）；
l 編寫客戶類（XWork的Action類）；
l 編寫保持元件對象的注冊類（例如Registry）；
l 寫代碼注冊元件（例如Registry.registerService(new MyExchangeRateService())）；
l 在客戶類中使用注冊類獲得服務（例如ExchangeRateService ers = Registry.getExchangeRateService()）
l 在客戶類中調用元件（例如String baseCurrencyCode = ers.getBaseCurrency()）
使用IoC，包括下面的過程：
l 編寫元件（例如ExchangeRateService）；
l 在XWork中注冊元件類（例如componentManager.addEnabler (MyExchangeRateService, ExchangeRateAware)））；
l 編寫實作enabler接口的客戶類（例如實作ExchangeRateAware接口的Action類）；
l 直接在客戶類中調用元件（例如String baseCurrencyCode = ers.getBaseCurrency()）
使用IoC有下面一些好處：
l 更容易測試：你可以使用enabler的方法傳遞模拟對象來更容易的測試你的對象；而不是必須建立整個容器環境來獲得需要的元件對象（與容器環境無關）；
l 元件描述自己：在執行個體化元件時，你很容易決定什麼是它需要的依賴關系，而不需要在代碼中或運作錯誤中查找；
l 使用反射機制很容易發現依賴關系：這對圖表生成和運作時優化都有好處；
l 當單獨一個類保持應用所有的元件時，避免super-uber-mega-factory模式；
l 堅持Demeter原則：每個類隻包含它實際使用的内容，這就鼓勵小的特定功能的類，而使得設計幹淨；
l 允許所有上下文環境獨立和明确的互相傳遞：本地線程在一個Web應用中可以很好的工作，但不适合高迸發的異步應用程式（如消息驅動應用程式）；
![利用Fiddler進行移動端弱網測試[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)