É uma boa ideia registrar visualizações e exibir modelos como singletons em um contêiner IOC?

5

Eu entendo os benefícios de injetar dependências em objetos, mas não encontrei muita orientação sobre os tipos de objetos a serem injetados e quando fazê-los singletons.

Se tomarmos como exemplo um aplicativo com os seguintes tipos de objetos:

  • Serviços (incluindo repositórios e serviços comerciais, como calcular o preço)
  • Visualizações
  • ViewModels

Serviços

Injetar serviços é o exemplo típico dado e é claro que eles não são registrados como singletons no container, pois são statelesss.

Foi a intenção original de que apenas os serviços devam ser injetados por contêineres?

Visualizações / ViewModels & outros objetos de longa duração com estado

A maneira geral de acessar um objeto de longa duração em vários lugares foi usar um registro (ou similar), assumindo que não podemos passá-lo como um parâmetro. Agora temos a opção de registrar o objeto como um singleton em um container e injetá-lo onde for necessário.

Não vejo nenhum problema em usar o singleton em uma abordagem de contêiner além da questão de remover o objeto do contêiner quando seu ciclo de vida terminar (não sei como isso será fácil - uso o Unity).

Estaria interessado em ouvir sobre quaisquer problemas que outras pessoas possam prever.

Como um lado interessante, o framework MVVM Light usa um ViewModelLocator em vez de injetar viewmodels.

    
por sturdytree 03.02.2013 / 14:13
fonte

3 respostas

2

Bem, depende do que você precisa. Se você nunca tiver duas ou mais vistas do mesmo tipo, então acho que está tudo bem registrá-las como singletons.

Mas, e se você tiver uma visualização composta de duas outras visualizações (e seus modelos de exibição), por exemplo, se você estiver comparando alguns dados? Você não poderá usar a mesma instância, pois precisará preencher as informações com dados diferentes.

Além disso, se você tiver muitas visualizações e algum tipo de navegação, onde cada visualização é criada quando chegar a ela, essas exibições singleton permanecerão em algum lugar quando você sair delas. O contêiner manteria uma referência e nunca seria coletado.

EDIT: Com relação ao seu comentário, acho que você não teria problemas se registrasse a visualização como um singleton. Dito isto, eu não faria isso. Eu costumo usar "singletons" para objetos stateless (ou statefull, mas onde o estado não pode ser alterado depois de configurado quando instanciado pela primeira vez) como repositórios, ou objetos que precisam ser instâncias únicas durante toda a vida útil da aplicação. No MVVM, seria um controlador responsável pelo gerenciamento de visualizações (para navegação). Eu deixo os pontos de vista, e seus modelos de visão como objetos normais, mesmo que no início eu esteja usando apenas um deles. Esta é apenas a minha preferência, no entanto.

PS: Eu não tenho experiência com o MVVM Light, mas usar o contêiner como um localizador de serviço é geralmente considerado um anti-padrão por muitos, já que você está introduzindo uma dependência ao contêiner. Suas visualizações e modelos de visualização (e modelos de domínio) devem ser o mais livres possível das construções de "infraestrutura", como o contêiner. Quando seu código chegar ao modelo de visualização, ele deve ter tudo o que precisa e não procurá-lo usando o contêiner.

    
por 03.02.2013 / 20:24
fonte
1

Esse problema realmente se resume ao ciclo de vida / escopo pretendido de suas instâncias.

Haverá uma única instância da sua turma durante a duração da inscrição? Então um "singleton" está bem. Eu citei singleton porque é realmente o escopo do aplicativo que está se referindo.

Uma boa visão geral de como os escopos são aninhados e a injeção de dependência funciona com isso, veja a introdução do PicoContainer (eu sou não sugerindo que você use o PicoContainer, apenas leia a introdução para entender essas coisas).

    
por 04.02.2013 / 02:16
fonte
1

Gostaria de acrescentar que nossos pontos de vista de Vaadin mantêm o estado no servidor, principalmente os controles que os formam. Se suas visualizações estiverem em uma situação semelhante em um ambiente multiusuário, você não poderá usar singletons. Você poderia usar algo próximo, como um Protótipo , para criar novas instâncias fora de um modelo. Você pode reutilizar as visualizações do mesmo usuário para diferentes iterações do mesmo fluxo de trabalho, para as quais você provavelmente utilizaria Flyweight ou senão você precisará redefinir o estado de visualização no início de cada reutilização, o que provavelmente não vale a pena.

Em qualquer caso, ocultar os detalhes por trás de um registro lhe dará a opção de alternar entre os dois modelos se você encontrar problemas no futuro.

    
por 04.02.2013 / 02:28
fonte