Applicazione Web: Dividi l'autenticazione dalla logica aziendale? E i valori di sessione?

Quindi quando si avvia un nuovo progetto web (principalmente ASP.NET) finisco sempre per discutere con me stesso: dove tengo la logica di autenticazione, le entità utente e come le combino con la mia altra logica di business (ad es. repository) ? E se avessi bisogno di variabili di sessione nella mia logica aziendale?

Quindi abbiamo i seguenti elementi, già definiti in un'applicazione modello MVC:

• ApplicationDbContext
• ApplicationUser
• ApplicationUserManager

Nel mio ultimo progetto ho avuto una libreria projectX.Core in cui ho incluso il ApplicationUser in una cartella denominata Entità, insieme alle altre mie entità di database. Tutto nell'applicazione MVC è stato rinviato al corretto ApplicationUser Ho unito il ApplicationDbContext a tutte le altre entità. Per me questo ha avuto i seguenti pro:

1. Potrei facilmente creare relazioni con la classe ApplicationUser (e quindi con la chiave esterna in db)
2. Non ho dovuto creare migrazioni separate in due progetti diversi.
3. Anche quando si crea un WebApi, il riferimento allo stesso ApplicationUser funziona perfettamente (tuttavia esiste un duplicato ApplicationUserManager definito in MVC e API)

Ma ha anche avuto:

Quando in tutta l'applicazione voglio conoscere l'utente attualmente loggato, ho bisogno del HttpContext che finisce nel riferire HttpContext in circa ogni libreria perché HttpContext.Current è sempre nullo all'interno di una libreria di classi (per quanto Lo so).

Insieme a questo viene in mente: variabili di sessione. Per esempio ho bisogno del carrello degli acquisti dell'utente corrente, come, quasi ovunque. (e potrebbe essere un utente anonimo, quindi ho bisogno dell'ID di sessione per interrogare il DB)

Il motivo per cui lo chiedo è, perché ho sentito alcune persone dividerlo e ho visto un progetto open source ticketDesk che fa esattamente quello Hanno implementato in modo tale che tutte le classi sopra elencate si trovino in un progetto diverso e una SecurityProvider sia inviata alla libreria del progetto Dominio che viene utilizzata per ottenere l'utente attualmente connesso. Non c'è mai una chiave esterna nel database per TicketDeskUser da Ticket , si basa sull'applicazione che serve un buon userId.

Quindi cosa pensi sia meglio? Mantenere la logica di autenticazione in MVC, inserirla in una libreria separata o combinarla con la logica aziendale? E come gestiresti le relazioni tra tutte le entità se non fosse l'ultima scelta?