我想知道為什么不顯式使用 IServiceProvider 來解決依賴項而不是單獨注入每個依賴項。換句話說,為什么要使用這種方法:public class A?{? ? private B _b;? ? private C _c;? ? private D _d;? ? private E _e;? ? public A(B b, C c, D d, E e)? ? {? ? ? ? _b = b;? ? ? ? _c = c;? ? ? ? _d = d;? ? ? ? _e = e;? ? }}而不是這個:public class A?{? ? private B _b;? ? private C _c;? ? private D _d;? ? private E _e;? ? public A(IServiceProvider sp)? ? {? ? ? ? _b = (b) sp.GetService(typeof(b));? ? ? ? _c = (c) sp.GetService(typeof(c));? ? ? ? _d = (d) sp.GetService(typeof(d));? ? ? ? _e = (e) sp.GetService(typeof(e));? ? }}請注意,我可能不會要求GetService所有類型,某些類型實際上可能是可選的(即有時使用,有時不使用)。第二種方法的優點是,如果 A 的依賴項發生變化,我們不需要在調用 A 的構造函數的每個地方進行更改,并且我們不需要擁有所有無論我們在哪里調用構造函數,依賴項都已經可用。
2 回答

蝴蝶不菲
TA貢獻1810條經驗 獲得超4個贊
有幾個原因。當您使用依賴項注入時,您將讓 DI 容器負責為您準備依賴項。這些類不應該關心如何創建依賴項。如果您切換到不同的 DI 庫,則必須更改所有類中的構造函數。
另一個小問題是,您必須在每個單元測試中為服務容器創建一個模擬,這不是一個大問題,但肯定會很煩人。
最后,當您必須將依賴項傳遞給嵌套類時,您的代碼將變得非常奇怪,更不用說您想要繼承的任何時候了。

翻過高山走不出你
TA貢獻1875條經驗 獲得超3個贊
這稱為服務定位器模式 ->
它有一些優點和缺點(在文章中描述),但它被廣泛視為一種反模式。
你聲明你自己調用構造函數(正如new SomeService(...)
我猜測的那樣),這是不使用 DI (或僅部分使用)的標志。
- 2 回答
- 0 關注
- 138 瀏覽
添加回答
舉報
0/150
提交
取消