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

> > >> Command-Query Responsibility Segregation >> > > Mi sento a casa :) Noi lo usiamo in combinazione con Event Sourcing (Axon > nell specifico come implementazione). > ​Ignorante che sono, ho "scoperto" il pattern CQRS solo di recente, anch'io combinato al pattern Event Sourcing (ref.:

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

2018-01-27 19:35 GMT+11:00 Matteo Vaccari matteo.vacc...@gmail.com [it-torino-java-jug] : > > > Si chiama Command-Query Responsibility Segregation, l'ho imparata da > Alberto Brandolini. > > Mi sento a casa :) Noi lo usiamo in combinazione con Event Sourcing

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

Non vorrei dire ma... ho trovato anche questa roba in giro per il "mondo".. Si salvi chi può.. Andare di reflection a runtime ( e chissà quante volte ) non pensate sia un pelo eccessivo? public static void copiaOggetto(Object oggettoDaCopiare, Object oggettoNuovo) { Class classOggettoDaCopiare =

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

eh eh non ho bisogno di un esempio, grazie :), la tua osservazione e' corretta ovviamente, e va tenuta in conto anche usando lombok o i getter, e come sicuramente sai, in tutti i casi di logica concorrente. Pero', appunto, i miei oggetti da "trasporto" sono molto stupidi e, nel caso sia richiesto,

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

*"* > > *[...] se mi consenti una considerazione public final nei campi va > bene fino ad un certo punto,* > *con oggetti mutabili credo che si lasci la porta aperta a disastri* *Scusa, c'e' uno "static" di troppo. Sono public final e, pertanto, non mutabili. L'unico modo per "caricarli" e'

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

2018-01-19 12:55 GMT+01:00 axa1...@gmail.com [it-torino-java-jug] < it-torino-java-jug@yahoogroups.com>: > > > Ciao Ciri! :D > Mi-iii-cco! :) > > Grazie a tutti perché questa discussione é sicuramente molto stimolante > per tutti. > > Ecco purtroppo la questione supporto e penetrazione

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

Ciao Ciri! :D Grazie a tutti perché questa discussione é sicuramente molto stimolante per tutti. Ecco purtroppo la questione supporto e penetrazione enterprise non è da poco. Come sappiamo la superiotità tecnica da sola non basta (ehm... Scala?), ma ci sono indizi che Oltre che da Google

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

2018-01-18 19:44 GMT+01:00 Tatiana Litvinova tatiana.litvin...@gmail.com [it-torino-java-jug] : > > > Ciao Federico, > > 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

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

> > 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

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

Tatiana Litvinova tatiana.litvin...@gmail.com [it-torino-java-jug] ha scritto il 16/01/2018 alle 22:28: > è *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

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

2018-01-16 22:28 GMT+01:00 Tatiana Litvinova tatiana.litvin...@gmail.com [it-torino-java-jug] : > > > Grazie Bruno e grazie a tutti per gli spunti. > > >> @Andrea: per curiosità, posso chiederti un esempio in Kotlin? > > Una data class in Kotlin data class

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

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

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

Eh sarebbe bello se il TDD rendesse impopolari i singleton :) In realtà si', li rende impopolari ma solo per i pochissimi che fanno veramente TDD! 2018-01-15 22:58 GMT+01:00 Massimo Ugues m.ug...@gmail.com [it-torino-java-jug] : > > > *L'uso dei builder per

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

Tatiana Litvinova tatiana.litvin...@gmail.com [it-torino-java-jug] ha scritto il 15/01/2018 alle 22:47: > con un servizio esterno al sistema ecc.), ma in molti casi la logica > vera poi non è molta, ed il sistema si limita per la maggior parte a > trasformare. > per questo motivo (e altri)

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

*L'uso dei builder per costruire oggetti nei test è stato reso popolare dal GOOS * Sinceramente non riesco a vedere una differenza sostanziale tra un builder e una fluent interface dei setter del POJO in oggetto. Come PRO la fluent interface ti

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

In realtà più che esempi volevo capire i criteri che utilizzate per prendere la decisione di "sdoppiare" il bean e perché. Ad esempio: creo sempre dei bean specifici per le "viste" sugli oggetti perché ... / creo un bean specifico per la "vista" di un particolare oggetto soltanto quando ...

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

L'uso dei builder per costruire oggetti nei test è stato reso popolare dal GOOS 2018-01-12 18:35 GMT+01:00 Federico Fissore feder...@fsfe.org [it-torino-java-jug] : > > > Ciao > > domandina del venerdì sera >

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

Io da poco ho scoperto MapStruct ( http://mapstruct.org/ ) che non trovo affatto male. Il giorno 15 gennaio 2018 18:59, bruno bossola bboss...@gmail.com [it-torino-java-jug] ha scritto: > > > Mah, per esempio nei servizi REST raramente serializzo l'oggetto,

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

Mah, per esempio nei servizi REST raramente serializzo l'oggetto, ma una "vista" di esso. Lo stesso in ingresso, ricevo una "vista" e da quella ottengo il vero oggetto. Questo per me e' l'esempio piu' comune, e faccio a mano, si, li testo di solito perche' quando creo l'oggetto "vero" di solito

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

Ciao a tutti, Vorrei allargare la questione posta da Federico. In quali occasioni ricorrete al mapping dei bean (trasformazione di un bean in un altro bean di struttura molto simile se non uguale)? Quando secondo voi è giustificata la creazione di questi bean differenti e quando invece è

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

In nessun ordine particolare: - A mano: tBean.setFieldA(sBean.getFieldA()); tBean.setFieldB(sBean.getFieldB()); - Builder - BeanUtils / Dozer e compari - Cose custom e truci con reflection - il .convertValue dell'ObjectMapper di Jackson: hai tutte le feature di Jackson (es i mixin) e