Quale livello dovrebbe contenere interazioni con risorse esterne o remote che non sono strettamente operazioni di dati?

Sembra che tu stia descrivendo l' architettura della cipolla , una forma di n- architettura di livello - che è solo un modo elegante per dire che ha componenti suddivisi in livelli.

Il livello su cui ti stai concentrando è il livello Infrastruttura . I dati sono la componente più comune dell'infrastruttura. Ma altre funzioni possono essere contenute in librerie separate nello stesso livello.

L'architettura è una cosa soggettiva. Il meglio che posso fare è offrirti come impostare il progetto.

Se vuoi essere veramente esplicito sui tuoi livelli, puoi usare le cartelle della soluzione per separare le cose.

AvvisoNonhoinclusolacartelladellasoluzionenellospaziodeinomi-èWhatever.Web,nonWhatever.Client.Web.Questaèun'altrachiamatasoggettiva,mal'hotrovatapiùpulitainquestomodo.Lecartelledellasoluzionenonsonoobbligateafarpartedellospaziodeinomicomelecartelledelprogetto.

Eallafine,unavoltachehoavutoun'intuizioneperqualipreoccupazioniappartengonoaqualelivello,hoscopertochenonavevonemmenobisognodellecartelledellasoluzione:

Bastadareun'occhiataaquesto,mièchiarocheimodellicondivisisononelCore,ilclientèilWebetuttoilrestoèlìpersupportarecomeinfrastruttura.Maseavessiiniziatoaotteneremoltipiùprogettiinognilivello,potreitornareall'organizzazioneconlecartelledellesoluzioni.

Perulteriorecredito,potreimenzionarechepersonalmenteilmiolivelloCore/Domainavrebbeinterfacceperiservizidiinfrastruttura:

Elalibreriadell'infrastrutturaimplementerebbequindiquell'interfaccia,cosìpotraisempre"scambiare" la dipendenza, con qualsiasi altra implementazione della libreria.

Penso che stiate estrapolando dalla terminologia piuttosto datata di "Data Layer" e "Data Access Layer"

L'assunzione implicita di questi termini è che hai un database di grandi dimensioni su cui la tua app scappa e vuoi separarlo e astrarlo dalle tue applicazioni o dal 'Business Layer'. Vuoi evitare di inquinare il tuo "dovrebbe essere disponibile per tutti gli usi, passato presente e futuro, dati" con la tua "logica aziendale del giorno"

Ma i casi di esempio sono un po 'più moderni nel loro modo di pensare, connettendosi a vari "Servizi" che forniscono funzionalità casuali al chiamante.

La risposta è che il tuo 'Business Layer' è ancora il re. Dovrebbe consumare servizi, alcuni dei quali sono il tradizionale "livello di accesso ai dati", ma il fatto stesso di astrarre quel livello significa che il livello aziendale non sa che quel servizio si trova nel livello dati.

Potrebbe essere solo un po 'incapsulato nella logica della memoria che è anche parte del tuo livello aziendale, potrebbe essere una terza parte esterna o potrebbe essere un file system locale.

Va bene ... una risposta semplice. Quando sto costruendo un progetto che ha un comportamento 'perpendicolare' (connettendosi a sistemi esterni, scrivendo su file di registro, ecc.) Lo faccio attraverso una libreria e generalmente faccio le chiamate ad esso nel livello aziendale. Il livello aziendale è in genere il luogo in cui è in corso l'azione che richiede l'accesso esterno e, inserendo la capacità in una libreria, è possibile riutilizzarlo in altri progetti. Le biblioteche sono buone. Mantieni i tuoi controller nel livello aziendale semplice e trasferisci le cose strane in librerie, altrimenti ti ritroverai bloccato più tardi.

Quando ho bisogno di creare qualcosa che non-livello-dati assomiglia a livello dati di solito è un odore di codice che indica che dovrei davvero mettere il codice in una libreria, o è solo qualcosa che sto tagliando temporaneamente.

Beh, non c'è una risposta generica, per alcuni è una questione di opinione quindi non risponderò in modo generico, ma prenderò i tuoi punti uno per uno. Sto rispondendo considerando che tutti quelli saranno progettati come interfaccia semplice. Non implementazione.

a web service that downloads a PDF of a SQL Server Reporting Services (SSRS) report.

Questo potrebbe essere solo una parte di una classe Util chiamata nel livello aziendale. Oppure, se consideri un po 'più ampio, si tratta di leggere i file, che siano remoti o meno. È solo un IMO di accesso ai dati. Solo l'implementazione true (not test :)) lo renderà remoto.

a library that sends email via SMTP or connects to a Microsoft Exchange mailbox and downloads messages in a folder structure

Quindi si tratta di leggere o scrivere in una casella di posta? Qual è la differenza con una lettura / scrittura su un database? La risposta è l'implementazione . Quindi la lettura / scrittura non elaborata è solo un accesso ai dati. Ovviamente l'analisi del file per generare alcuni dati o la scelta di cosa inserire nel file inviato appartengono al livello aziendale.

E dal momento che hai entrambi gli scambi SMTP / Micrisoft, avresti 2 diverse implementazioni. Business dirà quale vuole utilizzare.

direct interactions with the file system, such as writing to a log file, using built-in programming language functionality

Anche in questo caso si tratta di archiviazione, ancora in corso di lettura / scrittura dell'accesso ai dati. Nel mio caso ho FileService che può salvare qualsiasi file nel sistema e restituisce un oggetto FileInfo memorizzato nel database, quindi l'oggetto può essere collegato al file.