Ho ereditato un'API implementata usando ASP.NET WebApi 2. Le azioni sui controller sono tutte così:
public object Get(long id) {
LoginContext loginDetails = GetLoginDetails();
if (loginDetails.IsAuthorised) {
return _dependency.DoSomething(loginDetails, id);
}
return new HttpResponseMessage(HttpStatusCodes.Unauthorised);
}
Il _dependency avrà molti metodi tutti con firme simili, e avrà dipendenze proprie, e quelli useranno anche la classe LoginContext finché non raggiungerai il fondo dello stack di chiamate sul livello di accesso ai dati , dove viene effettivamente utilizzata la classe LoginContext . Le dipendenze sono attualmente tutte iniettate nel costruttore dal contenitore IoC.
Quindi ci sono un certo numero di problemi che mi infastidiscono: il controllo ripetitivo in ogni azione del controllore che l'utente è autorizzato e la necessità di avere un LoginContext su ogni metodo di ogni dipendenza referenziato ovunque dal controller. Ora, nel primo caso, ho creato un filtro azione che gestisce l'autenticazione e scrive un'identità personalizzata (che contiene i dettagli LoginContext ) di nuovo su HttpContext .
Questo lascia la carne della mia domanda: qual è il modo migliore per passare il mio LoginContext verso il basso attraverso i livelli al livello di accesso ai dati?
UPDATE: solo per chiarire, in risposta ad alcune delle domande seguenti, l'autenticazione stessa non viene controllata dal livello di accesso ai dati (anche se il livello aziendale farà ovviamente le cose in modo diverso in base al chiamante richieste di autorizzazione); ma piuttosto stiamo passando i dati raccolti durante il processo di autenticazione al livello di accesso ai dati, dove viene quindi utilizzato per accedere a particolari risorse o per problemi di infrastruttura come il controllo. Il problema rimane comunque, se ogni metodo del mio livello aziendale e ogni metodo del mio livello dati, prendi un LoginContext come uno dei suoi parametri, o ci sono modi migliori?