Il DTO può contenere metodi di supporto aggiuntivi?

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.

    
posta comiventor 14.03.2018 - 13:23
fonte

2 risposte

3

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.
risposta data 14.03.2018 - 17:19
fonte
1

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();
  }
}
    
risposta data 14.03.2018 - 19:42
fonte

Leggi altre domande sui tag