Controller e API DTO Architettura e organizzazione di classi in .net core con microservizi

Question

Controller e API DTO Architettura e organizzazione di classi in .net core con microservizi

#1 da (0 voti)

0

Stiamo sviluppando un sistema con un'architettura a microservizi grossolana. Abbiamo un'API che utilizza i controller e la logica di back-end con il repository Entity-Framework e diversi tipi di client che utilizzano questa API, il tutto in dotnet, quindi, typesafe.

Abbiamo bisogno di utilizzare una sorta di oggetti di trasferimento dati per la comunicazione tra l'API e i client. I client utilizzano le chiamate REST. Tuttavia, i nostri controllori devono nascondere alcune proprietà delle entità per:

diversi client (ad esempio metadati dell'entità per i client Web e nessun metadato per i client mobili)
diverse azioni del controller (ad esempio /Users/ restituisce un elenco di User DTO con solo nome e cognome, mentre /Users/{id} restituisce i dettagli dell'utente.)
diversi metodi REST (ad esempio, una Post richieste non avrebbe i timestamp in quanto è stata creata lato server)

La mia domanda è: quale sarebbe un buon design per la riusabilità? La migliore pratica è la creazione di nuove classi per tutte le richieste / risposte? Non vorremmo usare oggetti dinamici. Ho pensato al pattern Builder, ma non sono sicuro se questo si adatta qui.

rest class-design web-api asp.net-core controller

posta Yamaç Kurtuluş 13.04.2018 - 01:21

fonte

1 risposta

Leggi altre domande sui tag rest class-design web-api asp.net-core controller

Suggerimenti per la logica della sintassi OpenUp / Basic In Practice

score 0 · Accepted Answer

Il mio suggerimento è che tu usi una singola classe derivata che contiene tutte le proprietà in comune per una determinata entità. Ad esempio una classe User con nome, cognome e ultimo timestamp registrato.

Per rappresentare i dati provenienti dal dispositivo mobile, hai una versione derivata di User chiamata MobileUser che estende le proprietà esistenti con le tue meta informazioni relative a un utente mobile come tipo di dispositivo mobile, risoluzione, ecc.

Ovunque nell'applicazione web in cui è necessario solo User , si utilizza solo User . Nelle parti del tuo programma in cui devi differenziare, puoi implementarlo in User . Ad esempio, per persistere l'istanza User nel database, chiameresti il suo metodo User.save() . User.save() sarebbe responsabile del salvataggio di tutte le proprietà comuni a tutte le classi derivate e MobileUser.save() sarebbe responsabile del salvataggio delle proprietà specifiche per MobileUser . La logica imporrebbe anche l'uso di tabelle separate nel database, anche se sei libero di fare ciò che ritieni migliore.

Ovviamente, non riempire questi metodi con la logica di chiamare la query sql e così via. Affidati a un'altra classe per eseguire operazioni di persistenza generiche passando i dati che desideri persistere nel metodo. Puoi utilizzare una classe UserDAO per salvare% istanze diUser e MobileUserDAO per salvare% istanze diMobileUser. Non importa. La cosa fondamentale è che dove è richiesta la separazione nel tuo programma, lo fai senza doverne capire il tipo.

Per quanto riguarda la restituzione dei dati, un modello facciata probabilmente ti starebbe bene abbastanza bene qui. L'idea è di separare i dati effettivi delle entità da dove e come viene utilizzato. È possibile utilizzare una facciata che avvolge un'entità per rendere disponibili solo le proprietà che si desidera restituire mantenendo le proprietà private nascoste nella parte del programma che non la utilizza.