我工作中的應用是依靠Autofac作爲DI容器的,使我決定使用它,以及其他的原因之一,是代表工廠功能(見here)服務定位器比依賴注入更容易使用?
也能正常工作的所有情況在那裏我需要多次重新創建相同的元素,就像一些報告和相關屏幕一樣。一些報告(即使是相同類型的報告)是同時執行的,但它們只是通過用戶定義的參數進行更改,所以爲了創建實例注入工廠是有意義的(我認爲),傳遞免費參數並將其餘部分留給應用。
問題伴隨着每個報告由可變數量的子報告(任務)組成並且每個任務實現ITask接口。每份報告最多可以有50個不同的任務使用,每個任務都包含精確的業務操作。我有一個選擇是注入委託工廠並在需要時創建它們。
這些任務必須由工廠和喜歡的東西是動態生成的:
var myTaskA = _taskFactoryConcreteTaskA();
var myTaskB = _taskFactoryConcreteTaskB();
var myTaskC = _taskFactoryConcreteTaskC();
...
var myTaskZZ = = _taskFactoryConcreteTaskZZ();
需要大量的手工佈線(代表,構造,支持字段等等),而像
var myTaskA = _taskFactory.Create<ConcreteTaskA>();
var myTaskB = _taskFactory.Create<ConcreteTaskB>();
var myTaskC = _taskFactory.Create<ConcreteTaskC>();
...
var myTaskZZ = _taskFactory.Create<ConcreteTaskZZ>();
會特別是如果_taskFactory包裝了容器,如this other post所示,但它也意味着我正在使用服務定位器來創建我的任務。
我有哪些其他選擇可能適合解決此問題?
(注:有一個很好的機會,我完全偏離軌道,並且我要讀了很多有關DI,在這種情況下,任何的貢獻將更爲重要)
Martin Fowler的寫了這點:http://martinfowler.com/articles/injection.html#UsingAServiceLocator – mwilson
謝謝,這是什麼讓我再想想文章很多:HTTP: //blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx(並說服我購買這本書,但仍在等待它) – mhttk