Sto progettando un'API REST accoppiata con un livello di servizio che prende come input DTO e li produce come output. Funziona bene per la maggior parte delle chiamate di servizio in cui il DTO viene utilizzato per accedere a una libreria sottostante (un server OLAP incorporato) che esegue il lavoro.
C'è un servizio, tuttavia, in cui qualcosa sembra sbagliato. Il servizio è responsabile della creazione, manipolazione e memorizzazione facoltativa di oggetti che rappresentano report (si pensi ai report di Excel). Lo fa attraverso la libreria sottostante, che non espone i report come una risorsa. Poiché i report non rappresentano una risorsa lato server a meno che non siano persistenti (la persistenza è la mia stessa implementazione, non un concetto nella libreria), il servizio deve prendere un oggetto report che contiene tutte le informazioni necessarie per costruire un report da zero per essere apolidi.
Ho deciso che i metodi del servizio di report dovrebbero prendere un ReportDTO, manipolarlo e restituire la versione modificata. (Ciò includerebbe operazioni come lo scambio degli assi delle righe e delle colonne, l'ordinamento di un asse e il filtraggio di un asse.) Pensavo che, poiché ho tutte le informazioni disponibili nel ReportDTO necessarie per eseguire tutte queste operazioni, potrei anche eseguire li sul DTO e restituiscono una versione modificata piuttosto che duplicare il DTO come oggetto di dominio. Questo non vuol dire che il server non si interfaccia con nessun modello. Infatti, il codice lato server implica la convalida del report utilizzando una libreria di terze parti (cioè, il modello di validazione non è il mio - non ho un modello di dominio per il report stesso, solo DTO), salvando il report se il l'utente sceglie quindi ed esegue il report su un database per ottenere nuovi dati. Quindi c'è del lavoro da fare oltre alla manipolazione dei DTO, è solo che non è un lavoro legato a un modello di dominio di cui avevo bisogno per progettare me stesso, ma piuttosto uno fornito a me.
Dopo aver implementato le operazioni di cui sopra, ho realizzato qualcosa. Le operazioni sono operazioni logiche di business, no? Un DTO non dovrebbe avere questo. Poi ho avuto molti altri pensieri: "Va bene, va bene, eseguirò le operazioni nel livello di servizio ... Oh, aspetta.Il livello di servizio dovrebbe solo coordinare gli oggetti di dominio che contengono la logica di business, non avere la logica di business stessa. , Renderò il ReportDTO un oggetto dominio autentico. Crap, ora sto esponendo i miei oggetti di dominio dal livello di servizio .Questa è un'API, dovrei rimanere fedele alle DTO come input e output per il livello di servizio in modo che le modifiche il mio modello di dominio (o le modifiche nel modello di dominio di terze parti che utilizzo) non influenzano il contratto con i client di servizio. Bene, avrò un Report e un ReportDTO .... che hanno esattamente gli stessi membri perché il ReportDTO ha già tutte le informazioni necessarie per manipolare un rapporto (non solo eseguirlo, convalidarlo o salvarlo) a causa della decisione sul rapporto transitorio che ho preso a favore di un'API RESTful. "
Chiaramente ho neutralizzato ogni mia proposta di soluzione. Allora, che diamine faccio? Non voglio rendere i report di stato perché non li vedo davvero come una risorsa finché non vengono effettivamente salvati. Se li faccio dichiarare dovrò gestire una mappa o una cache di essi nel mio servizio e trattare con più clienti cercando di dare lo stesso nome al rapporto, implementare la sicurezza per garantire che un utente possa vedere solo i suoi report, ecc. Tutti questi problemi vanno via con un approccio apolidi. Gli effetti collaterali, tuttavia, sono i problemi di cui sopra. Ho sbagliato qualcosa da qualche parte? Per favore aiutami a risolvere questo problema di progettazione prima che diventi una parte permanente della mia API. Grazie.