擁有2個構造函數是正確的，一個用於依賴注入，另一個用於解析注入？

Question

我班上有2個構造函數：

public class VuelingCacheWebServices : IVuelingCacheWebService
    {
        public IVuelingCache apiConnector { get; set; }

        public VuelingCacheWebServices(IVuelingCache ApiConnector)
        {
            apiConnector = ApiConnector;
        }

        public VuelingCacheWebServices()
            : this(new VuelingCache())
        { }
    }

如您所見，我有一個構造函數，具體取決於IVuelingCache和一個默認構造函數，它創建一個傳遞給第一個構造函數的實例。 這是對的嗎？ 通過這種方式我擺脫了Factory類。

Answer 1

這是確保您擁有一個有效的IVuelingCache實例的IVuelingCache - 這個模式有一個名字 - 窮人的依賴注入。

有些人 認為 這是一種反模式，因為你很難將“默認”實現編碼到你的代碼中。

Answer 2

關於這種模式是一個好主意，存在一些爭論：

http://lostechies.com/chadmyers/2009/07/14/just-say-no-to-poor-man-s-dependency-injection/

在我看來，如果你有一個不是邏輯上的外部依賴的良好默認值 ，那么你應該提供該默認值。 如果您的“默認”確實不應該是默認值，或者會過於強烈地將彼此相距太遠的部分聯系起來，那么請不要使用該模式。

你通過這樣做來結合你的代碼，所以真的要長時間地考慮它是​​否會被用作本地可用的默認實現的便利默認值，或者如果你真的只是將它用作拐杖，並導致不適當的強耦合依賴。

此外，許多人提倡僅對所需的依賴項使用構造函數注入，並對可選的依賴項使用屬性注入。 當你使用窮人的DI模式時，你會產生一個可選（或默認）的依賴。 您可能需要考慮對這些可選依賴性情況使用屬性注入，因為這是許多人期望的模式。

Answer 3

不，這不是一個好主意，因為你的班級將成為有關IVuelingCache （ new VuelingCache() ）實現的知識。

Answer 4

您的方法存在一些問題：

1. 它使您的代碼不易理解。 不僅要編寫更多代碼，而且更難以看到類所依賴的依賴項。 當你有一個構造函數時，它立即清楚它的依賴是什么。
2. 它使類依賴於具體實例。 這使得很難將抽象和實現分開，從架構的角度來看可能很糟糕。
3. 它強制您在實現更改時對該類進行更改，這對可維護性是不利的。 比如說你的應用程序使用ICommandHandler<T>接口作為抽象來執行業務命令，並且你的類依賴於ICommandHandler<UpdateUserCommand>並指向具體的UpdateUserCommandHandler 。 當你以后想要在DurationLoggingCommandHandler<T> ，DeadLockRetryCommandHandler`中包裝任何ICommandHandler<T> ，你需要通過你的完整應用程序來替換所有依賴項，否則它只需要重新配置配置應用程序的啟動路徑。