COI e serviços sem estado. De curta duração ou instância única?


8

Dada uma estrutura de coleta de lixo, ao usar um contêiner do IOC para injetar serviços puramente sem estado, geralmente é melhor usar a vida útil de instância única do contêiner ou recriar o objeto cada vez que ele é usado e jogado fora, e todas as suas dependências, fora assim que você terminar com eles?

Respostas:


5

Você mencionou que seu serviço tem dependências.

Se alguma dependência em seu gráfico de dependências não for completamente sem estado, ou se uma de suas dependências em seu gráfico de dependências for modificada para não ser mais completamente sem estado, o sistema inteiro falhará. E os erros que você receber provavelmente serão muito enigmáticos, dificultando a descoberta do problema.

Digamos que você seja uma equipe de desenvolvedores trabalhando no projeto. É altamente improvável que todos estejam cientes de que a configuração do IOC exige que todos esses componentes permaneçam completamente sem estado. Eles podem saber agora, mas essa consciência desaparecerá com o tempo. E se você contratar um cara novo, ele / ela também não estará ciente.

Definitivamente, eu configuraria o contêiner do IOC para retornar uma nova instância sempre. É simplesmente a escolha mais segura, imho.

Eu certamente não me preocuparia com recursos. O custo de construção e coleta de lixo de objetos é provavelmente insignificante em comparação com, por exemplo, apenas uma única pesquisa no banco de dados.


Então, você está dizendo para criar novas instâncias sempre, porque talvez não saiba como tornar um serviço sem estado?
Matthew Flynn

1
Não. O que estou tentando dizer é que pode ser difícil prever como sua base de códigos será modificada ao longo do tempo. Mas a pergunta é extremamente geral, então eu estou dando uma resposta extremamente geral;)
Pete

Sim, a pergunta foi deliberadamente geral, porque eu não queria arriscar meu próprio viés. Ainda decepcionado por não receber uma resposta com base na experiência, mas esse é o raciocínio mais bem pensado, então obrigado.
PDR

4

A instância única foi o comportamento padrão do Spring por um motivo - uma instância única de um serviço sem estado está consumindo menos recursos do que a criação constante e a coleta de lixo de muitas instâncias. Além disso, não há perigo real no compartilhamento de um serviço sem estado, mas há alguns problemas reais de escalabilidade com a criação de várias instâncias de um serviço.

Então, eu diria que a instância única provavelmente será sua amiga.


0

Sem outro contexto, acho que isso realmente não importa.

Você pode obter os benefícios de objetos de curta duração a partir de uma única instância, se ela simplesmente criar os objetos de curta duração para cada chamada, e você pode obter os benefícios de uma única instância de muitos objetos de curta duração, se eles simplesmente agirem como pesos volantes .

É claro que é desnecessariamente barulhento configurá-lo de uma maneira, apenas para delegar o contrário. Então, acho que você deve apenas ter um palpite, se é provável que você adicione estado, e se sim, se será um estado persistente / global (por exemplo, ao adicionar um cache) ou um estado de vida curta / local.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.