Se la nostra applicazione sfrutta Ninject e utilizza la tecnica della dependency injection, probabilmente ci troveremo nella situazione in cui, anche nell'ambito di un Hub di ASP.NET SignalR, abbiamo bisogno di iniettare le dipendenze tramite il costruttore:
public class CustomersHub : Hub { private ICustomerRepository _repository; public CustomersHub(ICustomerRepository repository) { if (repository == null) throw new ArgumentNullException("repository"); _repository = repository; } // ... }
In condizioni normali, questo Hub non è utilizzabile: ASP.NET SignalR, infatti, utilizza un dependency resolver simile a quello di ASP.NET MVC, che però per default non è configurato per sfruttare Ninject e quindi non è in grado di invocare il costruttore.
Dobbiamo quindi crearne uno personalizzato, che utilizzi questo container per risolvere la dipendenza da ICustomerRepository, e il modo più semplice è quello di creare una classe che erediti da DefaultDependencyResolver:
public class NinjectResolver : DefaultDependencyResolver { private IKernel _kernel; public NinjectResolver(IKernel kernel) { _kernel = kernel; } public override object GetService(Type serviceType) { var result = _kernel.TryGet(serviceType); if (result == null) return base.GetService(serviceType); return result; } public override IEnumerable<object> GetServices(Type serviceType) { var result = _kernel.GetAll(serviceType); return result.Union(base.GetServices(serviceType)); } }
L'idea di base è assolutamente simile al Dependency Resolver di ASP.NET MVC, ossia un oggetto che restituisca i componenti richiesti tramite i metodi GetService e GetServices. Andando nello specifico, l'implementazione che abbiamo realizzato sfrutta in prima istanza il kernel di Ninject per risolvere la dipendenza, sfruttando poi l'implementazione della classe base come fallback: è importante farlo perché comunque ASP.NET SignalR sfrutta questo resolver anche per costruire servizi interni di sistema, che non sono registrati su Ninject.
Per attivare questo resolver, è sufficiente specificarlo in fase di configurazione del routing:
public partial class Startup { public void Configuration(IAppBuilder app) { ConfigureAuth(app); app.MapSignalR(new HubConfiguration() { Resolver = new NinjectResolver(NinjectWebCommon.Kernel) }); } }
Commenti
Per inserire un commento, devi avere un account.
Fai il login e torna a questa pagina, oppure registrati alla nostra community.
Approfondimenti
Eseguire una GroupBy per entity in Entity Framework
Eseguire attività pianificate con Azure Container Jobs
Implementare il throttling in ASP.NET Core
Paginare i risultati con QuickGrid in Blazor
Utilizzare i primary constructor in C#
Mascherare l'output di un valore all'interno dei log di un workflow di GitHub
Effettuare il binding di date in Blazor
Configurare dependabot per aggiornare le dipendenze di terze parti con GitHub Actions
Esportare ed analizzare le issue di GitHub con la CLI e GraphQL
Supporto ai tipi DateOnly e TimeOnly in Entity Framework Core
Migrare una service connection a workload identity federation in Azure DevOps
Gestire la cancellazione di una richiesta in streaming da Blazor
I più letti di oggi
- Utilizzare Docker Compose con Azure App Service
- Utilizzare QuickGrid di Blazor con Entity Framework
- Modernizzare le applicazioni WPF e Windows Forms con Blazor
- ASP 3 per esempi
- annunciato #netstandard 2.1. .NET Core lo supporterà a partire da #netcore3, così come le prossime versione di #xamarin, #mono e #unity.il supporto per #netfx 4.8, invece, non ci sarà. https://aspit.co/bq2
- Steel Style CheckBox per Silverlight 4.0