Um bom artigo para aprender sobre o escopo e o ciclo de vida do controle do Autofac: o escopo do ciclo de vida é equivalente a uma unidade de trabalho na sua aplicação, uma unidade de trabalho inicia o escopo do ciclo de vida no início, e então os serviços que exigem essa unidade de trabalho são separados do escopo do ciclo de vida.
Oscilações Vitalícias
Crie Oscilações Lifetme
Crie um escopo manualmente e faça o descarte. Os escopos de vida útil são descartáveis e monitoram a eliminação dos componentes, então certifique-se de sempre chamar "Descartar()" ou envolvê-los em instruções "usando".
Escopos Vitalícios do Selo
Às vezes, você pode precisar compartilhar alguns serviços dentro de uma Unidade de trabalho, mas não quer usar conveniências globais de compartilhamento, como o modo singleton. Por exemplo, o ciclo de vida por requisição de uma aplicação web, caso em que você pode usar o InstancePerMatchingLifetimeScope para identificar seu ciclo de vida e serviço.
Por exemplo, há um componente que envia e-mails, e a lógica de transação precisa enviar mensagens várias vezes, então o serviço de e-mail pode ser compartilhado em cada fatia lógica de transação. Se você não quiser que o componente de e-mail seja um singleton global, pode configurá-lo da seguinte forma.
Adicionando Registros a um Escopo Vitalício
O Autofac permite adicionar "em tempo real" ao criar um ciclo de vida. Isso pode ajudar quando precisar fazer uma espécie de sobreposição limitada de registro por "soldagem por pontos" ou se geralmente precisar de algo extra em um escopo que não quiser registrar globalmente. Você faz isso passando um lambda para o BeginLifetimeScope() que pega um ContainerBuilder e adiciona registros. (Ao criar um ciclo de vida, registre serviços adicionais sem registro global)
Escopo da Instância
O escopo da instância determina como uma instância é compartilhada entre as requisições. Ao solicitar um serviço, o autofac pode retornar um único escopo de instância, uma nova instância por escopo de dependência ou um singleton em um contexto, como uma thread ou uma requisição HTTP por escopo de vida. Isso se aplica a instâncias retornadas de uma chamada explícita ao Resolve(), bem como a instâncias criadas internamente pelo contêiner para satisfazer as dependências de outro componente.
- Instância por Dependência
- Instância Única
- Instância por Escopo de Vida
- Instância por Escopo Vitalício Correspondente
- Instância por Solicitação
- Instância por Propriedade
- Escopo de Thread
Instância por Dependência
Também chamado de transitório ou 'fábrica' em outros contêineres, ele retorna uma instância única cada vez que um serviço é solicitado. Se não houver um ciclo de vida especificado, esse é o comportamento padrão.
Cada dependência do Resolve retorna um novo componente.
Instância Única
A mesma instância é retornada em todas as requisições e escopos aninhados.
Instância por Escopo de Vida
Esse escopo pode ser aplicado a escopos aninhados. O componente de escopo por vida tem no máximo uma instância dentro do escopo aninhado. Isso é útil para objetos específicos de uma única unidade de trabalho que podem precisar aninhar unidades lógicas adicionais de trabalho. Cada escopo aninhado de vida receberá uma nova instância da dependência registrada.
Quando você analisa o componente de instância por escopo de vida, há apenas uma instância em cada escopo aninhado (por exemplo, por unidade de trabalho).
Instância por Escopo Vitalício Correspondente
Isso é semelhante ao Escopo de Instância Por Vida, mas o controle pode ser compartilhado com instâncias mais precisas. Quando você cria um ciclo de vida aninhado, pode rotulá-lo ou dar um nome. Um componente com escopo por vida combinada terá no máximo uma única instância por escopo aninhado que corresponde a um nome próprio. Isso permite a criação de singletons com escopo, onde ciclos aninhados podem compartilhar componentes sem criar instâncias globais.
Útil para unidades individuais de trabalho, como requisições http, criadas como ciclos de vida aninhados. Se uma vida útil aninhada for criada por requisição HTTP, então qualquer componente com escopo por vida terá uma instância por requisição HTTP. (Mais informações sobre o escopo vitalício por pedido abaixo.)
Na maioria das aplicações, apenas um nesting hierárquico de contêineres é necessário para representar uma unidade de trabalho. Se múltiplos níveis aninhados forem necessários (por exemplo, transação global >pedido>transação), componentes podem ser criados para serem compartilhados em um nível específico via tags.
Quando um ciclo de vida aninhado é iniciado, as tags são associadas a esse ciclo de vida. Você terá uma exceção se tentar resolver um componente de escopo de vida por correspondência quando não existe um escopo de vida corretamente nomeado. (Se o ciclo de vida da tag não salva for analisado, uma exceção ocorrerá.)
Instância por Solicitação
Alguns tipos de aplicação naturalmente têm uma semântica do tipo "pedido", como ASP.NET MVC. Entre esses tipos de aplicação, é útil ter algum tipo de "singleton por solicitação". Instância por requisição se constrói sobre instância por escopo de vida correspondente, fornecendo uma tag de escopo de vida bem conhecida, um método de conveniência de registro e integração para aplicações comuns tipos (uma instância por requisição é construída sobre o escopo de vida por correspondência, fornecendo uma tag de vida bem conhecida, um método de conveniência de registro e integração para tipos de aplicações comuns). Basicamente, é por escopo de vida correspondente.
Isso significa que, se não houver uma requisição atual e você analisar um componente registrado com base em instância por requisição, uma exceção será lançada. Há um FAQ detalhado que explica como trabalhar com vidas por requisição.
O login do hiperlink está visível.
Instância por Propriedade
Possui o tipo de relacionamento implícito, criando um novo ciclo de vida aninhado. Dependências podem ser limitadas à instância host ao registrarem com instance-per-owned.
Neste exemplo, o serviço ServiceForHandler terá escopo para a vida útil da instância MessageHandler própria.
Escopo de Thread
Você pode consultá-lo
O login do hiperlink está visível.
Combate real
Estou usando o modo Instância Por Escopo Vitalício.
No winform, quando a chamada é executada, ele usa um contexto de banco de dados a cada vez, como mostrado na figura abaixo:
_dbContext.GetHashCode();
13583655
_dbContext.GetHashCode();
13583655
_dbContext.GetHashCode();
13583655
No caso de multithreading e concorrência, se você usar o mesmo contexto de banco de dados, encontrará exceções ao adicionar, excluir, modificar ou verificar o banco de dados.
Quero que o autofac retorne um novo objeto toda vez que clico no botão, o código é o seguinte:
Como mostrado abaixo:
(Fim) |
Postado em 19-09-2020 12:51:52
|
|
|
|
Postado em 09-08-2022 09:58:24