Padrões de uso/casos de uso para DI ou quando começar a usá -lo

Question

Não tenho certeza para quais casos de uso se deve usar DI no aplicativo. Eu sei que os serviços de injeção como PlaceService ou CalculationService etc se encaixa muito bem, mas também devo criar meus objetos de domínio com di como um User? O que é se o User tem apenas um construtor que requer um primeiro e último nome. Isso é solvável com DI?

Devo usar o DI para criar as instâncias para interfaces de conjunto/lista ou isso é puro exagerado?

Eu uso o Guice principalmente.

Answer 1

A regra que eu uso é, em geral, para favorecer a injeção de dependência, exceto quando o objeto pode ser construído com valores puramente primitivos e não há / uma chance mínima de que o objeto possa ser substituído por outra implementação.

No entanto, para objetos de domínio, principalmente se seus objetos não constituem um Modelo de domínio anêmico, ou seja, onde objetos são apenas sacos de getters e setters, pode ser útil ter objetos que, por exemplo, possam se persistir em um armazenamento de dados, etc. para esse tipo de objetos, injeção de dependência e Salva pode ser uma combinação poderosa.

Guice tem uma solução específica para o tipo de problema representado por objetos como seu objeto de usuário chamado AssistedInject, embora coisas semelhantes também sejam possíveis com outros contêineres leves ou usando algo que o construtor ou padrões de adaptador.

Answer 2

A resposta do IG0774 é um bom ponto de partida. Além disso, gostaria de oferecer esta regra de polegar:

Na terminologia de Design orientado a domínio, você deve dar Serviços, mas não para entidades ou objetos de valor.

Em outras palavras, Di se encaixa bem com objetos sem estado de vida conceitualmente de longa duração, dos quais geralmente existem um ou um número conhecido em uso.