Empresas
Empregos
  • Sobre nós
  • Soluções
    • Publicação de vagas
      Publique sua vaga e receba candidatos qualificados em 48h.
    • Avaliações de candidatos
      Mais de 500 testes técnicos e psicológicos, mais anti-fraude.
    • Headhunting
      Busca executiva personalizada do início ao fim.
    • Folha de Pagamento + EOR
      Dispersão de folha e EOR em mais de 15 países da LATAM.
  • Preços
  • Empregos

0

217
Visualizações
.NET Core Dependency Injection cómo manejar múltiples objetos

Como dice el título, tengo una aplicación .NET Core a la que intento convertir y aprovechar la inyección de dependencia de Microsoft integrada.

Tengo un objeto y una clase base para el objeto, lo llamo CommunicationBase y Communicator . Cuando mi aplicación se inicia y lee el archivo de configuración, puedo tener una cantidad N de objetos para instanciar.

Anteriormente, antes de cambiar a Inyección de dependencia, en algún lugar de mi rutina de inicio, donde leía el archivo de configuración, tenía una variable List<CommunicationBase> a la que instanciaba y agregaba objetos de Communicator y, al mismo tiempo, configuraba algunos de los valores base. properties, que cambiaron según la cantidad que había en mi configuración y las propiedades de cada uno en config.

¿Cómo lograría esto con DI?

Entiendo que en mis servicios, registraría el tipo para que pueda inyectarse en otros constructores de clases.

Por ejemplo, services.AddTransient<CommunicationBase, Communicator>(); pero según tengo entendido, esto solo registra los tipos con DI. Puedo inyectarlo en una clase y tener una instancia aleatoria de uno de ellos.

¿Cómo tendría N número de instancias y podría establecer las propiedades de cada una a medida que creo la instancia?

¿O es este un escenario en el que DI no es necesario o no funcionará y necesito hacerlo de la forma en que lo estaba haciendo antes?

¡Gracias!

over 4 years ago · Santiago Trujillo
2 Respostas
Responde à pergunta

0

Modificaría ligeramente el enfoque que se muestra aquí . Así que definiría alguna enumeración que luego se usaría para decidir qué instancia devolver.

Configuración de clases de muestra y la enumeración:

 public enum CommuniationType { False, True, Other, } public abstract class CommunicationBase { public CommunicationBase(CommuniationType communiationType) { CommuniationType = communiationType; } public bool IsConnected { get; set; } public CommuniationType CommuniationType { get; protected set; } } public class Communicator : CommunicationBase { public Communicator(CommuniationType communiationType) : base(communiationType) { } }

Ahora, en el lugar donde tiene acceso a la colección de servicios (por ejemplo, en ASP.NET, el lugar sería el método Stratup.RegisterServices ) define sus objetos de clase concreta y los registra, como en el código de ejemplo a continuación (en la parte inferior, hay también son clases de prueba que usan el objeto CommunicationBase para probar propósitos):

 public class Program { static void Main(string[] args) { var serviceCollection = new ServiceCollection(); SetupNObjects(serviceCollection); serviceCollection.AddTransient<CommunicationBaseServiceResolver>(serviceProvider => communicationType => { var implementations = serviceProvider.GetServices<CommunicationBase>(); return implementations.First(x => x.CommuniationType == communicationType); }); serviceCollection.AddScoped<FalseTestClass>(); serviceCollection.AddScoped<TrueTestClass>(); var serviceProvider = serviceCollection.BuildServiceProvider(); var f = serviceProvider.GetService<FalseTestClass>(); var t = serviceProvider.GetService<TrueTestClass>(); } // Here you should take care of registering objects, after reading config. // That would be best place to do that. static void SetupNObjects(ServiceCollection serviceCollection) { var comFalse = new Communicator(CommuniationType.False); comFalse.IsConnected = false; var comTrue = new Communicator(CommuniationType.True); comTrue.IsConnected = true; serviceCollection.AddScoped<CommunicationBase>((serviceProvider) => comFalse); serviceCollection.AddScoped<CommunicationBase>((serviceProvider) => comTrue); } } public class FalseTestClass { private readonly CommunicationBase communication; public FalseTestClass(CommunicationBaseServiceResolver resolver) { communication = resolver(CommuniationType.False); } } public class TrueTestClass { private readonly CommunicationBase communication; public TrueTestClass(CommunicationBaseServiceResolver resolver) { communication = resolver(CommuniationType.True); } }
over 4 years ago · Santiago Trujillo Relatório

0

En primer lugar, debe tener claras las diferencias entre la vida útil transitoria, de alcance y única. Para comprender cómo funciona la lista de objetos de Communicator que se leerán de su archivo de configuración.

Un enfoque para resolver su pregunta es

  1. Cree una interfaz ICommunicatorList con un método para obtener una Lista, es decir, puede envolver la lista de comunicadores.
  2. Cree una clase que herede de ICommunicatorList (por ejemplo, llamada CommunicatorList), con un campo privado para su lista de comunicadores. En el método constructor, configure su campo privado con la lista de comunicadores, o aquí puede recibir como un parámetro de la sección del archivo de configuración para iterar y completar su campo privado.
  3. en esta clase implemente su código para devolver la lista de comunicadores.
  4. Ahora, en su archivo de inicio, ahora puede crear el servicio services.AddTransient<ICommunicatorList>(x => new CommunicatorList(parámetros));
over 4 years ago · Santiago Trujillo Relatório
Responde à pergunta
Encontrar trabalhos remotos

Descubra a nova forma de encontrar um emprego!

melhores empregos
Principais categorias de trabalho
Empresas
Postar vaga Preços Comercial
Jurídico
Termos e Condições Política de privacidade
© 2026 PeakU Inc. All Rights Reserved.
Andres GPT
Recomende algumas ofertas para mim
Preciso de ajuda