Re: [Jug-Torino] Quale approccio usare per mappare un bean in un altro?

2018-01-17 Thread Federico Tomassetti f.tomasse...@gmail.com [it-torino-java-jug]
Ciao a tutti, ho trovato molto interessante questa discussione. I due approcci che preferirei sono quello della mappa e l'uso di Kotlin. Riguardo l'approccio con la mappa, mi sembra un modo di aggirare il problema di stare usando Java. Quest'approccio mi fa tornare in mente un articolo di Martin

Re: [Jug-Torino] Quale approccio usare per mappare un bean in un altro?

2018-01-17 Thread bruno bossola bboss...@gmail.com [it-torino-java-jug]
> > Mettiamo il caso che tu abbia iniziato a sviluppare senza creare gli > oggetti "vista"... > Questo e' il default per me. > ...ad un certo punto ti sei accorto che *per un caso particolare* invece > era indispensabile. Che cosa fai: > 1. crei una "vista" solo per quell'oggetto e gli altri co

Re: [Jug-Torino] Quale approccio usare per mappare un bean in un altro?

2018-01-17 Thread Tatiana Litvinova tatiana.litvin...@gmail.com [it-torino-java-jug]
ср, 17 янв. 2018 г. в 14:29, bruno bossola bboss...@gmail.com [it-torino-java-jug] : > 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 c

Re: [Jug-Torino] Quale approccio usare per mappare un bean in un altro?

2018-01-17 Thread Tatiana Litvinova tatiana.litvin...@gmail.com [it-torino-java-jug]
ср, 17 янв. 2018 г. в 11:04, Andrea Cerisara andreaceris...@gmail.com [it-torino-java-jug] : > > > Ciao Tatiana, > Ciao Andrea! imho é il problema perché riscrivendo quel modulo in Kotlin abbiamo smesso > di fare discussioni come questa. > Può essere, forse bisognerebbe provare per credere, per

Re: [Jug-Torino] Quale approccio usare per mappare un bean in un altro?

2018-01-17 Thread Tatiana Litvinova tatiana.litvin...@gmail.com [it-torino-java-jug]
ср, 17 янв. 2018 г. в 8:45, Roberto Franchini ro.franch...@gmail.com [it-torino-java-jug] : > Ci sono un paio di talk, uno suo ed uno mio, un po' datati, tra i video > del JUG, mi pare il titolo sia Kill Bean 1 e 2 > Appena riesco a trovare tempo sufficiente provo a cercare invece di tempestarvi

[Jug-Torino] Meeting stasera

2018-01-17 Thread Roberto Franchini ro.franch...@gmail.com [it-torino-java-jug]
Ciao a tutti, ricordo che stasera si terra' il nostro consueto meeting: Potete ancora iscrivervi: https://www.meetup.com/JUGTorino/events/246048923/ -- Roberto Franchini "The impossible is inevitable" https://github.com/robfrank/ https://twitter.com/robfrankie https://www.linkedin.com/in/robfr

Re: [Jug-Torino] Quale approccio usare per mappare un bean in un altro?

2018-01-17 Thread bruno bossola bboss...@gmail.com [it-torino-java-jug]
> > 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

Re: [Jug-Torino] Quale approccio usare per mappare un bean in un altro?

2018-01-17 Thread Andrea Cerisara andreaceris...@gmail.com [it-torino-java-jug]
Ciao Tatiana, imho é il problema perché riscrivendo quel modulo in Kotlin abbiamo smesso di fare discussioni come questa. Diciamo che architetturalmente ci piace avere un bean apposito ogni qual volta saltiamo da un layer all' altro (quindi strategia `sempre e comunque` perché é consistente e ci