>
> Stai dicendo che parti senza la duplicazione degli oggetti finché non
> trovi un caso per cui si verificano entrambe le condizioni (es. il primo
> oggetto che non riesci a serializzare in json). A quel punto cosa fai? Crei
> una "vista" soltanto per quell'oggetto? Rifattorizzi, introducendo le
> "viste" json per tutti gli oggetti che vengono serializzati?
Di solito genero un value object con dei metodi from/to rispetto al mio
oggetto vero (i.e. un costruttore che crea in base all'oggetto vero, una
factory the ritorna l'oggetto vero a cui passo extras). In genere e' un
oggetto molto triste, niente metodi a parte quei due citati, serve solo a
essere serializzato / deserializzato: quindi niente getters, setters, o
rumenta del genere. .
Per esempio, assumendo che ho l'oggetto di dominio "User", quello farlocco
e' fatto cosi: (scusate il nome, stavo evendo coca zero...)
public class UserZero {
private final UUID uuid;
private final String name;
public UserZero(User user) {
this.uuid = user.uuid();
this.name = user.name());
}
public User create(UserRepository users, Magic magic) {
...
}
}
(nota che potrebbe essere necessario a seconda del serializzatore che usi
e/o le annotazioni che vuoi mettere eliminare i final e ficcarci un
costruttore vuoto farlocco... di solito scelgo la strada + facile)
E per le Entity (ammesso che le usi)?
>
No, non so cosa sono :) Se posso porto i miei oggetti di dominio fino al DB
e ce li spalmo sopra / leggo da mediante un ORM semplice tipo JDBI
<http://jdbi.org/>
....sarebbe un altro argomento interessante da affrontare, magari in un
> thread a parte...
E posso anche dire: *mai usato EJB in vita mia!!! *
(si, a volte ho scritto codice che ci andava dentro, ma that's it... il
massimo da me usato e' stato JPA)
Ciao,
Bruno
2018-01-16 21:28 GMT+00:00 Tatiana Litvinova [email protected]
[it-torino-java-jug] <[email protected]>:
>
>
> Grazie Bruno e grazie a tutti per gli spunti.
>
> Facendo retrospettiva, per me devono verificarsi queste due condizioni (
>> *entrambe*): [8<]
>>
>
> Direi molto chiaro come trigger. Ma...
>
> E poi YAGNI, se posso lo evito. Ho sempre tempo a rifattorizzare dopo.
>>
>
> Invece qui un po' meno. Stai dicendo che parti senza la duplicazione degli
> oggetti finché non trovi un caso per cui si verificano entrambe le
> condizioni (es. il primo oggetto che non riesci a serializzare in json). A
> quel punto cosa fai? Crei una "vista" soltanto per quell'oggetto?
> Rifattorizzi, introducendo le "viste" json per tutti gli oggetti che
> vengono serializzati?
>
> E per le Entity (ammesso che le usi)?
>
>
>>
>> - ormai faccio solo piu' microservizi (alla faccia di quelli che mi
>> prendevano per il culo nel 2013 :)) quindi se vuoi la mia architettura
>> internamente e' generalmente molto semplice
>>
>> Questo sarebbe un altro argomento interessante da affrontare, magari in
> un thread a parte.
>
> Per quanto riguarda invece la verbosità di Java (lamentata implicitamente
> anche da Federico, mi pare), il problema c'è ma non so se è *il* problema.
> L'interfaccia fluente con dei nomi dei metodi corti è più carina e più
> trendy, ma fa davvero tanta differenza nella sostanza? Le mappe... capisco
> i pro, ma l'assenza di un controllo sintattico sulle chiavi mi fa paura. E
> il refactoring?
>
> @Andrea: per curiosità, posso chiederti un esempio in Kotlin?
>
> Ciao,
> Tatiana
>
>>
>
