Quello che chiedi è supponente, quindi la risposta è: dipende!
La concezione principale di Onion Architecture è che le dipendenze puntano verso l'interno del cerchio ma mai fuori. Dovresti scegliere le responsabilità dei livelli dell'applicazione. Come hai scritto:
The way I currently did it is add Active Directory operations classes directly into MVC's Model folder.
Questo suona come se fosse una responsabilità del livello applicazione, che naturalmente può essere buono o cattivo, solo tu puoi decidere.
Ma vedo tre modi principali per implementarlo:
-
Livello applicazione: nel livello dell'interfaccia utente al momento attuale
-
Livello di servizio: accedi all'AD dalle tue classi di servizio, in questo modo puoi avere un accesso "condiviso" di detta funzionalità
-
Livello repository: allontana tutte le query / gli aggiornamenti correlati a AD necessari.
Se la tua paura è che la tua azienda cambierebbe l'autenticazione da AD per dire TACACS, puoi avere implementazioni di IAuthenticationEngine in un assembly che riguarda il livello di infrastruttura.
Per riassumere tutto questo: questa è una preoccupazione per l'infrastruttura, quindi dovrei semplicemente separare queste responsabilità dai punti 2 o 3, forse 2 e 3. Di nuovo tutto dipende dalle tue esigenze.
Per rispondere alla tua domanda in commento: Vedo che sei caduto nella tipica trappola di seguire gli esempi presentati su The Onion Arch. Dato che al momento hai il flusso del tuo programma, stai solo creando livelli di astrazione senza alcun reale vantaggio se non la difficoltà. Ti suggerisco di leggere questa risposta che ho scritto su StackOverflow, su una domanda simile che stai affrontando in questo momento. In breve, è su di te che potrebbe non è davvero necessario che il codice scorra tutti questi livelli. Usa solo le sezioni verticali dei livelli.