Riutilizzo di un DTO di primo livello come figlio in un altro DTO

7

Qual è la raccomandazione riguardante il riutilizzo di DTO da bambino in un altro DTO?

Utilizzo API Web ASP.NET (C #) e consumo i risultati con Angular 1.x (non sono sicuro se ciò sia davvero importante).

Ho i seguenti DTO

class SiteDto {
 public int SiteId {get;set;}
 public string Name {get; set;}
 public DateTime CreatedDate {get;set;}
  ...
}

class SiteEventDto {
 // pk
 public int SiteEventId {get; set; }
 // fk
 public int SiteId {get; set;}
 public DateTime EventStartDate {get; set;}
 public DateTime EventEndDate {get; set;}
 ...
}

Voglio restituire un elenco di SiteEvents con un nome di sito (ad esempio). C'è una raccomandazione per il collegamento tra SiteEvent e il sito per ottenere queste informazioni sui genitori? Ad esempio, vedo le seguenti possibilità:

  1. Riutilizza DTO esistente: utilizza il DTO del sito esistente come proprietà all'interno del DTO SiteEvent (ad esempio public SiteDto ParentSite { get; set; } )

    • Pro:
      • Riutilizzo del codice
      • Scalabile
    • Contro:
      • Potenzialmente un sacco di extra bloat (per le chiamate basate sul web / json in particolare) a causa di proprietà non necessarie e forse di gerarchie parentali aggiuntive
  2. Crea nuovo DTO genitore: crea un DTO figlio specifico per questa attività (ad esempio class SiteEventSiteDto { ...) e fai riferimento a ciò tramite una proprietà figlio su SiteEventDto

    • Pro:
      • Riduci ulteriore ingombro dai campi inutilizzati
    • Contro:
      • Riutilizzo del codice minimo
  3. Struttura della classe Flatten: Appiattisci la struttura della classe per includere semplicemente una proprietà "SiteName" in SiteEventDto (ad esempio public string SiteName { get; set; } )

    • Pro:
      • Riduci ulteriore ingombro (anche di più)
    • Contro:
      • Riutilizzo del codice minimo

Probabilmente ha senso esaminare ciascun caso individualmente e valutare le seguenti domande:

  • Prevedo la necessità di ulteriori proprietà al di fuori dell'oggetto principale?
  • Quanto è difficile aggiungere una nuova proprietà in una struttura piatta?
  • Quanta larghezza di banda costa davvero l'utente?

Credo che le mie domande alla comunità siano:

  • È prassi comune riutilizzare un DTO per più di un controller (scenario n. 1, sopra) o è considerato una cattiva pratica per qualche motivo? Oppure, ha più senso creare un nuovo DTO figlio o utilizzare una struttura piatta quando possibile?
  • E infine, le mie ramblings sopra sembrano un buon approccio a questo problema?
posta Adam Plocher 01.10.2016 - 08:22
fonte

1 risposta

6

Riutilizza il DTO esistente, Crea nuovo genitore DTO e struttura della classe Flatten

Scegliere tra codice riutilizzabile ( a volte ci fa sentire come la quadratura della cerchia ) o la personalizzazione ( a volte ci fa sentire come avere un deja vu ) è una questione di esigenze e preferenze.

Hai già esposto pro e contro di ogni soluzione. Ora devi bilanciarli:

  • Questi professionisti che si adattano meglio alle tue esigenze .

  • Questi contro che non ti impediscono di soddisfare i requisiti .

Valuta e rispondi alle seguenti domande:

Do I foresee a need for additional properties of the parent object?

Fornendo proprietà aggiuntive ( che potrebbero sembrare non necessarie a prima vista ) potresti salvare le chiamate sul server. Ridurre la concorrenza e risparmiare risorse del dispositivo è sempre benvenuto in qualsiasi sistema.

How difficult is it to add a new property in a flat structure?

Dipende da quanto è difficile recuperare la proprietà:

  • Abbiamo bisogno di eseguire query aggiuntive? Quanti? Che tipo di domande?
  • È necessario rendere più complessa la query effettiva? Che tipo di complessità stiamo introducendo?
  • Dobbiamo chiamare servizi esterni? ....

How much bandwidth is the bloat going to really cost the user?

  • Con quale frequenza gli utenti chiederanno il DTO complesso? (Se richiesto solo una volta durante la "sessione". C'è qualche costo?)

  • È obbligatorio creare risorse leggere?

  • È importante usare meno larghezza di banda possibile?

  • C'è qualche tipo di limitazione del consumo di larghezza di banda?

Ok ... Troppe domande

Tutti questi tipi di domande potrebbero portare a un'ottimizzazione prematura. Inizia con il più semplice. Applicare il principio KISS .

Infine ...

And lastly, do my ramblings above seem like a good approach to this problem?

È necessario conoscere il progetto e i requisiti, al fine di dire quale soluzione è consigliabile / buona / migliore

Finora, tutti e 3 sono legittimi e "buoni" se risolvono il problema.

    
risposta data 01.10.2016 - 10:14
fonte

Leggi altre domande sui tag