首頁(yè) 猿問(wèn) 依賴注入(DI)“友好...

依賴注入(DI)“友好”庫(kù)

C# .NET

白板的微信 2019-06-13 17:02:13

依賴注入(DI)“友好”庫(kù)我正在考慮C#庫(kù)的設(shè)計(jì)，它將具有幾種不同的高級(jí)功能。當(dāng)然，這些高級(jí)函數(shù)將使用實(shí)心類設(shè)計(jì)原則越多越好。因此，可能會(huì)有供消費(fèi)者定期直接使用的類，以及那些更常見(jiàn)的“最終用戶”類的依賴關(guān)系的“支持類”。問(wèn)題是，設(shè)計(jì)庫(kù)的最佳方法是：DI不可知論-雖然添加基本的“支持”一兩個(gè)常用的DI庫(kù)(結(jié)構(gòu)地圖、尼尼微等)似乎是合理的，但我希望消費(fèi)者能夠使用任何DI框架的庫(kù)。不可用的-如果庫(kù)的使用者沒(méi)有使用DI，那么庫(kù)仍然應(yīng)該盡可能容易使用，從而減少用戶創(chuàng)建所有這些“不重要”的依賴關(guān)系所需的工作量，這僅僅是為了獲得他們想要使用的“真實(shí)”類。我目前的想法是為常見(jiàn)的DI庫(kù)提供一些“DI注冊(cè)模塊”(例如，一個(gè)StructurereMap注冊(cè)表，一個(gè)Ninject模塊)，以及一個(gè)非DI并包含到這幾個(gè)工廠的耦合的Set或Factory類。思想？

查看完整描述

3 回答

一只甜甜圈

TA貢獻(xiàn)1836條經(jīng)驗(yàn) 獲得超5個(gè)贊

編輯2015：時(shí)間已經(jīng)過(guò)去了，我現(xiàn)在意識(shí)到這整件事是一個(gè)巨大的錯(cuò)誤。IoC容器非常糟糕，DI是處理副作用的非常糟糕的方法。實(shí)際上，這里的所有答案(以及問(wèn)題本身)都是要避免的。只需注意副作用，將它們從純代碼中分離出來(lái)，其他一切要么就會(huì)就位，要么就會(huì)變得無(wú)關(guān)緊要和不必要的復(fù)雜性。

原答覆如下：

我不得不面對(duì)同樣的決定SolrNet..我一開(kāi)始的目標(biāo)是對(duì)DI友好和容器無(wú)關(guān)，但是隨著我添加了越來(lái)越多的內(nèi)部組件，內(nèi)部工廠很快變得無(wú)法管理，由此產(chǎn)生的庫(kù)變得不靈活。

最后我寫(xiě)了我自己的非常簡(jiǎn)單的嵌入式IoC容器同時(shí)也提供了一個(gè)溫莎設(shè)施和一個(gè)尼尼姆模塊..將庫(kù)與其他容器集成只是一個(gè)正確連接組件的問(wèn)題，所以我可以輕松地將它與Autofac、Unitity、StructurereMap等集成在一起。

缺點(diǎn)是我失去了new提高服務(wù)水平。我還依賴于CommonServiceLocator我本可以避免的(我可能會(huì)在將來(lái)重構(gòu)它)，以使嵌入式容器更易于實(shí)現(xiàn)。

這里有更多的細(xì)節(jié)。博客帖子.

質(zhì)檢似乎依賴類似的東西。它有一個(gè)IObjectBuilder接口，它實(shí)際上是CommonServiceLocator的IServiceLocator，有幾個(gè)方法，然后它為每個(gè)容器實(shí)現(xiàn)這一點(diǎn)，即NInjectObjectBuilder和一個(gè)常規(guī)的模塊/設(shè)施，即質(zhì)數(shù)傳遞模..然后它依賴于IObjectBuilder實(shí)例化它需要的東西。當(dāng)然，這是一種有效的方法，但就我個(gè)人而言，我不太喜歡它，因?yàn)樗鼘?shí)際上是在容器周圍傳遞太多，使用它作為服務(wù)定位器。

單軌實(shí)施器它自己的容器同時(shí)，它也實(shí)現(xiàn)了好的IServiceProvider..此容器在整個(gè)框架中使用，通過(guò)公開(kāi)知名服務(wù)的接口。..要獲得混凝土容器，它有一個(gè)內(nèi)置服務(wù)提供者定位器..這個(gè)溫莎設(shè)施將此服務(wù)提供者定位器指向Windsor，使其成為所選的服務(wù)提供者。

底線：沒(méi)有完美的解決方案。與任何設(shè)計(jì)決策一樣，這個(gè)問(wèn)題需要在靈活性、可維護(hù)性和便利性之間取得平衡。

反對(duì) 回復(fù) 2019-06-13