DI的使用模式/使用案例或何時開始使用它

Question

我不確定在應用程序中應該使用哪種用例。我知道像PlaceService或CalculationService等注入服務非常適合，但我是否也應該使用DI創建我的域對象，如User？如果User只有一個構造函數需要第一個和最後一個名字，那該怎麼辦？ DI可以解決嗎？

我應該使用DI爲Set/List接口創建實例嗎？或者這是純粹的矯枉過正？

我主要使用guice。

Answer 1

我使用的規則通常是傾向於依賴注入，除非對象可以用純原始值構造，並且對象可能被另一個實現替換的可能性很小。

但是，對於域對象，特別是在對象不構成對象的情況下，即對象只是獲取者和設置者的袋子的情況下，例如，可以將對象保存到數據存儲庫等等。對於那些類型的對象，依賴注入和Salve可以是一個強大的組合。

對於類似於您的User對象（稱爲AssistedInject）的對象所帶來的問題類型，Guice有一個特定的解決方案，但對於其他輕量級容器或使用某些構建器或適配器模式也可能有類似的情況。

Answer 2

ig0774的答案是一個很好的起點。此外，我想提出這個經驗法則：

在Domain-Driven Design的術語，你應該爲DI服務，而不是實體或值對象。

換句話說，DI符合概念上長壽命，無狀態的對象，其中通常使用一個或一個已知的數字。