Codice comune per la trasformazione di un'entità

Question

Codice comune per la trasformazione di un'entità

#1 da (1 voti)

1

La mia api sta esponendo informazioni centrate su un'entità Company . Le aziende sono complesse e possono contenere Vendor s direttamente o possono contenere sub-società che contengono i fornitori stessi.

Un consumatore della nostra API ha richiesto l'aggiunta di diversi nuovi endpoint dai quali è possibile richiedere informazioni su un'azienda e i suoi fornitori; il problema è che, per questi nuovi endpoint, desiderano che tutti i fornitori della società siano elencati e integrati con i fornitori delle proprie sub-compagnie.

La trasformazione sarebbe la seguente:

Company1         ==========>     Company1
|                                |
+--Vendor1                       +--Vendor1
+--Company2                      +--Vendor2
   |                             +--Vendor3
   +--Vendor2
   +--Company3
      |
      +--Vendor1
      +--Vendor3

Attualmente, l'architettura del progetto si basa su Clean-Architecture / Onion-Architecture con quattro principali categorie di progetti:

Web Api
Use Cases
Accesso ai dati
Oggetti business

La logica di trasformazione è in realtà, molto più complicata rispetto all'esempio sopra, e saranno necessari più posti, quindi posizionare la logica direttamente nei metodi del controller API è ovviamente un no.

Poiché si tratta di un problema di interfaccia, si potrebbe argomentare per avere una funzione nel progetto WebAPI che esegue la trasformazione. Ciò richiederebbe le classi meno recenti dal momento che il DTO che rappresenta i dati inviati al richiedente potrebbe essere ri-proposto, ma questo metodo rappresenta la capacità minima di riutilizzo (stiamo anche considerando di fare un'API non http).

Il metodo a cui mi propongo è creare un UseCase dedicato per l'unione. Questo mi sembra il miglior equilibrio tra riusabilità e semplicità.

Un'altra opzione è creare il metodo nello stesso oggetto business Company , perché cosa sa come trasformare un'azienda meglio di quella azienda? Semplice da usare, tutti i dati e la logica sono in un unico posto e molto riutilizzabili. Ma, quindi, dobbiamo capire quale formato restituire questa trasformazione e tutto ciò può diventare molto complicato se vogliamo tentare di riutilizzare gli oggetti di business già presenti come formato di ritorno.

Sono sicuro che ci sono altre opzioni a cui non ho pensato.

Quali sono le migliori pratiche / consigli architettonici su dove collocare questa logica di trasformazione dell'entità?

object-oriented enterprise-architecture clean-architecture

posta TheCatWhisperer 13.11.2018 - 20:42

fonte

1 risposta

Leggi altre domande sui tag object-oriented enterprise-architecture clean-architecture

Client (app-server) vs ID unici generati da DB Come ridimensionare meglio le letture in un sito Web: a CQRS o non a CQRS?

score 1 · Accepted Answer

In breve, stai prendendo una gerarchia di oggetti e schiacciandoli (un po ').

Mettere questo in un caso d'uso avrebbe senso se i casi d'uso possono essere composti da altri casi d'uso, o se ci fosse solo un caso d'uso che aveva bisogno di questo comportamento.

A meno che non si riesca a trovare una buona ragione di business per questa visione consolidata dei venditori di una società diversa da "Non voglio vedere i fornitori duplicati", mi prendo in considerazione un caso d'uso per questo.

Se riesci a trovare una buona ragione di lavoro, una nuova classe di business sarebbe la strada da percorrere e la sposterai nella vasta area aziendale dell'architettura.

Quindi di nuovo, forse KISS prevale qui, e tutto ciò che serve è un metodo su un oggetto Company che restituisce un elenco univoco di fornitori dell'intera gerarchia aziendale. Sei libero di usarlo in ogni caso d'uso che ritieni opportuno.