在應用程序擴展性的預期中使用IoC容器

我知道還有類似的問題Here但我認爲我的這個擴展了一點。在應用程序擴展性的預期中使用IoC容器

我最近一直在研究已經生產了大約一年的應用程序，沒有問題，也沒有真正的擴展計劃。該應用程序具有很少依賴性，並使用DI但沒有容器。

現在我正在將應用程序擴展到公司指令的更廣泛的範圍，這使我實現了使用IoC容器。這裏的問題是將一個容器添加到我之前認爲不需要的代碼的開銷。

我作爲我前進的具體問題是：

在規劃和編碼想必不會擴大小很多的應用程序，我應該實現的容器在期待那個場景，如這些可能存在自己和這樣的期待，我會更好地從一開始就實施一個容器，因此在擴展時已經存在框架。
如果在將應用程序擴展到超出其初始意圖時執行容器變得繁瑣，那麼這是設計不佳的標誌嗎？

編輯：

我使用固體原則（盡我的能力），並在我的應用廣泛的接口目前的問題是，更關係到在使用IoC容器，而不是DI的和它本身。前面提到的應用程序是一種自帶的DI樣式，我正在添加一個容器，問題出現在這個容器中。

來源

2014-02-06 Evan L

我是Clean Code特別是YAGNI的大粉絲。「你不會需要它」。如果您不需要項目中的DI，請不要使用它。如果您需要DI進行單元測試但不需要容器，請不要使用容器。簡單是它自己的優點。儘可能保持簡單。

如果爲將來的擴展性準備項目現在花費時間或金錢，請不要這樣做。你可以在將來支付。因爲未來可能永遠不會到來。如果確實如此，那肯定不會像預測的那樣，你的準備也不會像你想象的那樣有用。

我一直在那些有很多「可擴展性」代碼的項目中，您至少可以刪除75％的源代碼，並且所有必需的功能仍然存在。我沒有想到項目經理想知道爲了實現這樣一個基本功能而花了那麼長時間。不要這樣做。規劃您的項目，獲取您的要求並實施它們。如果可擴展性是一項要求，那麼計劃它，估算它，讓你的經理知道。我的猜測是他們不希望可擴展性太差。他們寧願有另一個工作計劃。

這就是說，顯然你在學習。如果它不花費時間和金錢，請繼續開發下一個程序，以便更容易地擴展。只要留意成本。

來源

2014-02-06 15:42:34 nvoigt

我知道YAGNI會上來，這正是我引起這個問題的原因。我同意成本絕對是一個因素，但正如在其他答案中所述，將容器添加到小應用程序的開銷很小，我同意，因爲我以前做過這件事，而且它很簡單。在你看來，你會如何定義YAGNI的「需求」？沒有任何代碼需要*容器，但它肯定可以提高可管理性。否則，我完全同意你的第三段。如果實施成本高昂，您可以讓您的經理們思考如此長的時間。 –

就Yagni而言，如果我的項目沒有從某些方面獲得直接利益，那就不需要了。例如，DI使我的項目單元測試更容易。所以我需要它。容器不會授予任何額外的好處，因爲除了生產使用和硬編碼單元測試之外，我不需要切換實現。因此不需要添加容器。其他人可能有不同的要求，所以他們會針對各自的項目得出不同的結論。 – nvoigt

DI不僅有助於單元測試。它還有助於鬆散耦合和關注點分離。從用戶的角度來看，這不是直接的要求，但它們很重要。無論你需要一個容器是另一個問題，但我通常更喜歡經過測試和維護的解決方案，而不是你自己的。 – Kenneth

我認爲在即使是最小的應用程序中使用DI也是有益的，並且有很少的缺點（開銷非常小）。使用容器可能總是比滾動更快（更不用說更穩定）了。
理想情況下，如果您應用了堅實的原則並針對接口進行編程，而不是具體類型，則只需修改組合根。這意味着你一直在使用DI而沒有容器，並且有DIY解決方案。如果不是，那麼轉向DI可能會更難一些。

我建議不要一次性處理整個重構。以小增量逐步進行並隨時測試。這是最高的機會不打破任何現有的功能，它會讓你在應用程序的整體設計中發現錯誤

來源

2014-02-06 15:24:55 Kenneth

非常感謝您的回答以及關於逐步重構的反饋。 –

1. When planning and coding smaller applications that presumably will not expand much, should I implement a container in anticipation that scenarios such as these may present themselves and in such anticipation I would be better off implementing a container from the start so upon extension the framework already exists。

爲什麼不定位自己未來的成功？即使在一個小應用程序中，好處也很多，而且額外的工作量很小。

2. Is it a sign of poor design if implementing a container when extending an application beyond its original intention becomes cumbersome?

有些人可能會爭辯說，設計最初由於沒有使用容器而很差。你可能會改進設計，所以如果做得對，這不會是件壞事。初衷是什麼？要緊密耦合，難以測試？我說，繼續你的想法。

順便說一句，如果你不使用接口的無償使用，目前，我建議這是一個很好的開始。

來源

2014-02-06 15:44:03

比較手動進樣和自動注射：

1）

作爲另一個答覆中提到，使用容器從一開始就爲未來的打樣解決方案在我看來是一個好主意。不過，我強烈建議用一個好的編碼標準文件來跟進這個過程。爲了說明這一點，請查看我在生產系統中看到的以下代碼。

public class MyClass 
{ 
IUnityContainer _container; 
public MyClass(IMyDependentInterface dpenedentclass, IUnityContainer container) 
{ 
_container = container; 
//........ 
} 

public void DoSomething() 
{ 
    var obj = _container.Resolve<ISomeOtherInterface>(); 
    obj.DoAction();  
}  
}

不知不覺中在這裏建立了一個反模式（服務定位器？）。正如你所看到的，在這個世界上似乎沒有失效證明的設計。所以，不要猶豫，在您的編碼標準文件中添加看似明顯的內容。

2）

如果移動到自動注射是困難的，它是一件壞事的標誌。它可以是設計，但不會低估前面說明的糟糕設計糟糕設計的力量。

來源

2014-02-06 17:46:50 Jimmy

感謝您的回答，我知道早期實施易*且需要很少的開銷 - 我將來可能會朝着這個方向發展，因爲我的組織總是喜歡爲我的軟件提供*好點子* =） –

在應用程序擴展性的預期中使用IoC容器

回答

相關問題