103 messaggi dal 26 febbraio 2007
Ciao,

Ho creato una classe all'internod i un progetto che sarà utilizzando all'interno di un'applicazione ASP.Net Core 2.1.

Questa classe è fatta così:

private IMemoryCache _memoryCache;
private readonly IHttpContextAccessor _httpContextAccessor;

public NodeConfiguration(IMemoryCache memoryCache, IHttpContextAccessor httpContextAccessor)
{
}

public GetConfiguration()
{
//TODO utilizzerà cache e dati dell'utente loggato per estrarre dei dati
}


Per poterla utilizzare devo instazione per forza il costruttore ogni volta passandomi i due valori di cache e http? Essendo questo metodo molto all'interno della mia funzione (in pratica ho una chiamata API che a sua volta chiamata un paio di classi prima di richiedere questa). In pratica dal Controller sono costretto a portarmi dietro dentro ogni classe i valori di IMemoryCache e IHttpContextAccessor, non esiste un modo migliore per fare questo?

Ho provato a leggere degli articoli sulle Dependency Injection ma non mi è ancora chiaro...

Grazie
11.443 messaggi dal 09 febbraio 2002
Contributi
Ciao Federico,

Per poterla utilizzare devo instazione per forza il costruttore ogni volta passandomi i due valori di cache e http?

No, registri questa classe come servizio e poi ci pensa ASP.NET Core a risolvere le sue dipendenze.

Leggi queste due discussioni che forse chiariranno meglio la questione.
http://forum.aspitalia.com/forum/post/420254/Accedere-AppSettings-Classe.aspx
http://forum.aspitalia.com/forum/post/421131/Ancora-Appsettings.aspx

Poi se hai domande continuiamo la discussione qui.

ciao,
Moreno

Enjoy learning and just keep making
103 messaggi dal 26 febbraio 2007
Grazie, la guida mi è stata molto utile.

Ho implementato la DI, ma adesso ho un problema (o probabilmente la sto usando male)


Middleware

public async Task Invoke(HttpContext httpContext, IUserData userData)
{
userData = new User();
//Setto le proprietà
}

Controller

public MioController(IUserData userData)
{
userData //NON HA I VALORI SETTATI NEL Middleware
}

Startup
services.AddTransient<IUserData, User>(); //Ho provato anche AddScope


In pratica mi perdo i valori inseriti nel middleware

PS: sto facendo un uso sbagliato? In pratica in questo caso vorrei ritornare dei dati che ho ottenuto tramite l'elaborazione del Middleware (che si occupa di controllare se la login corretta oppure no)
11.443 messaggi dal 09 febbraio 2002
Contributi
Ciao,


userData = new User();

No, questa assegnazione non è corretta perché il parametro userData non ti viene passato come riferimento. L'istanza che stai creando qui sarà visibile solo all'interno del metodo Invoke del tuo middleware.
Inoltre, la dependency injection serve appunto a evitarti di dover creare delle istanze con la parola chiave new.

Quando esprimi una dipendenza da IUserData in questo modo, come parametro del metodo Invoke...
public async Task Invoke(HttpContext httpContext, IUserData userData)

...ASP.NET Core ti fornisce già un'istanza. Non devi crearne tu un'altra. Devi semplicemente usare i metodi e le proprietà esposte da IUserData per cambiare il suo stato interno (es. per impostare il nome dell'utente). Ad esempio:
public async Task Invoke(HttpContext httpContext, IUserData userData) {
  userData.NomeUtente = "Mario";
  await Next(httpContext);
}



services.AddTransient<IUserData, User>(); //Ho provato anche AddScope

Con AddTransient non può funzionare perché quando il middleware successivo ha bisogno anche lui di un'istanza di IUserData, ASP.NET Core gli passerebbe una nuova istanza, diversa da quella su cui avevi impostato il NomeUtente. Usare AddScoped quindi è il modo corretto perché l'istanza ha lo stesso ciclo di vita della richiesta HTTP e perciò ASP.NET Core la riusa ogni volta che un componente ne ha bisogno (middleware, controller, ecc...). Ovviamente finché la richiesta HTTP è ancora in corso, poi l'istanza viene distrutta.



sto facendo un uso sbagliato?

Uhm, sì, perché stai reinventando la ruota.
ASP.NET Core ha già un meccanismo che ti permette di sapere se la richiesta è autenticata o no e consiste nell'impostare la proprietà User dell'oggetto HttpContext che il tuo middleware già riceve.
Leggi il paragrafo "Un esercizio per comprendere autenticazione e autorizzazione" di questo articolo che ti mostra appunto come realizzare un middleware di autenticazione e uno di autorizzazione.
http://www.aspitalia.com/articoli/asp.net-core/autenticazione-autorizzazione-aspnetcore-p-2.aspx#title_1

Lì puoi appunto vedere come si imposta la proprietà User e come poi puoi rileggerla per capire se la richiesta è autenticata e che privilegi ha l'utente.

Però, questo dovrebbe restare solo un esercizio o al limite dovrebbe essere impiegato in situazioni particolari in cui non puoi usare ASP.NET Core Identity, che è ovviamente la soluzione preferita per creare un sistema di membership completo, basato su un database di utenti locali.

Abbiamo scritto varie cose su ASP.NET Core Identity, puoi iniziare da qui, che ti mostra le possibilità di personalizzazione:
http://www.aspitalia.com/articoli/asp.net-core/personalizzare--aspnet-core-identity.aspx

ciao,
Moreno
Modificato da BrightSoul il 04 febbraio 2019 14:17 -

Enjoy learning and just keep making
103 messaggi dal 26 febbraio 2007
Grazie mille adesso è tutto molto più chiaro

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.