2
對「業務線」應用程序使用依賴注入時有多個工廠是否「正確」？通過「業務線」應用程序，我的意思是像SalesForce.com或具有許多功能和相關窗口/窗體的CRM系統的應用程序。實際上，SalesForce.com可能是一個不好的例子。 HTTP GET/POST機制創建了調用DI容器的明顯組合根。但是，例如，長期運行的WPF應用程序是什麼？爲所有可能的功能創建對象圖似乎是浪費的，因爲在該會話期間不會調用其中的許多功能圖，或者如果該人的角色限制了他們對應用程序的使用，則可能永遠不會。在許多Windows WPF應用程序中依賴注入
看來解決方案是使用DI容器來解析每個窗口/窗體，因爲它是需要的。但是：
- 這違背只是解析時，編排根，在這種情況下，解決在應用程序啓動父窗口的DI原則。
- 這將需要工廠創建窗口/窗體，以防止在應用程序代碼中引用DI容器 。看起來工廠會迅速繁殖。
這似乎增加而不是減少複雜性，因爲要求創建工廠的唯一函數創建一個「人工」組合根來隱藏對DI解決方法的調用。
我也明白，理想情況下，工廠不應該引用DI容器，但在這種情況下有一個對象圖來解決和不使用DI容器將需要我自己解決依賴關係，顯然是擊敗了使用DI容器。
說實話，現在的應用程序並不那麼複雜，工廠也不會使問題複雜化很多。但是，我使用DI編寫了這個獨立的應用程序作爲學習練習，以向我和我所在的小型開發團隊介紹它。大多數團隊不熟悉DI，並且只需要額外的代碼和類就可以簡單地隱藏DI容器的引入，就會想到DI的有效性。我沒有選擇Mark Seemann的「.NET中的依賴注入」的副本，但WPF示例似乎太簡單，無法覆蓋這個確切的場景，正如在介紹性文本中可能會預期的那樣。他的示例在OnStartup事件中創建了一個MVVM表單。
任何洞察讚賞。謝謝。