Il DTO può contenere metodi di supporto aggiuntivi?

Question

Il DTO può contenere metodi di supporto aggiuntivi?

#1 da (3 voti)
#2 da (1 voti)

2

Ho un DTO come sotto

class OnlineProfileDTO {
  @JsonProperty("likes")
  SummaryDTO likes;

  // lots of other complex fields similar to above
}

class SummaryDTO {
  @JsonProperty("count")
  int count;
}

Ora ogni volta che ho bisogno di Mi piace contare in un convertitore DTO a DBEntity, ho bisogno di controllare se onlineProfileDTO.getLikes() è nullo o meno prima di chiamare onlineProfileDTO.getLikes().getCount() . In alternativa, prendi NullPointerException e ignoralo. Ma questo dovrà essere fatto per tutti i campi complessi che possono essere potenzialmente nulli.

Chiamare un metodo comune come di seguito può evitare la ripetizione sopra -

getCount(SummaryDTO anySummaryDTO) {
  if (anySummaryDTO != null) {
    return anySummaryDTO.getCount();
  }
  return 0;
}

Una volta definito sopra il metodo, è possibile utilizzarlo per ottenere il conteggio Like come segue:

getCount(onlineProfileDTO.getLikes())

La mia domanda è dove dovrebbe essere posto idealmente questo metodo? Più specificamente, è corretto spostare questo metodo sulla classe DTO che di solito contiene i campi oggetto di trasferimento insieme ai loro getter e setter solo?

Approccio 2: Si può anche definire il metodo getLikes () in modo che restituisca il conteggio direttamente ma il suo tipo di dati restituito sarà int.

java dto

posta comiventor 14.03.2018 - 12:23

fonte

2 risposte

Leggi altre domande sui tag java dto

Utilizzo di file puramente statici e codificati per i test dell'interfaccia utente o di alcune logiche per determinare quali dati inviare indietro Architettura per lavorare con diversi dispositivi

score 3 · Answer 1

Ci sono più svantaggi che professionisti.

Contro:

Se questo Dto viene passato attraverso la rete, alcuni framework possono provare a serializzare il metodo. Usando Swagger su questo Dto, ad esempio, mostrerà un attributo example sulla documentazione se hai un metodo getExample . Questo può essere ignorato nella maggior parte dei framework, ma è necessario ricordare che ogni volta che si aggiunge un metodo in Dto
Un Dto dovrebbe essere "fittizio". Il getCount può essere interpretato come parte del codice aziendale. Quindi, la Dto non è il posto migliore.
I metodi su Dto hanno la tendenza a crescere e sarà più difficile modificare gli attributi effettivi che vengono utilizzati in questi metodi, perché ci saranno molti metodi che trattano i campi che tu, forse, vorresti eliminare o spostare da un altro Dto.

Pro:

Se stai cercando il codice che si occupa dei dati Dto, il Dto place è probabilmente il primo posto che lo sviluppo visiterà per trovare.

score 1 · Answer 2

Questa mi sembra una domanda X / Y. Il tuo problema sembra essere veramente con null s qui.

Cerca di evitare i null il più possibile. Come hai visto, è un dolore con cui lavorare.

Per i sub-DTO complessi puoi usare il modello a oggetti nulli.

Inoltre, puoi lasciare il campo (privato) nullo e usare java.util.Optional nel getter:

public Optional<Summary> getLikes() {
  return Optional.ofNullable(likes);
}

E poi usalo in questo modo:

int count = onlineProfile.getLikes().map(Summary::count).orElse(0);

In questo modo devi esplicitamente definire cosa succede quando il valore non è presente, il che è positivo.

Infine, in casi semplici puoi usare le strutture di Jackson per evitare di avere sempre un null nel tuo oggetto, ad es. così:

class OnlineProfileDTO {
  private int likes;

  @JsonCreator
  public OnlinceProfileDTO(
      @JsonProperty("likes") SummaryDTO likes,
      @JsonProperty("...") ...) {
    this.likes = likes == null ? 0 : likes.getCount();
  }
}