Secondo me il problema è dettato principalmente dalla verbosità di Java (anche noi abbiamo spesso discussioni sul quando/come/se creare bean appositi).
A lavoro stiamo sperimentando parti di backend con Kotlin e devo dire che il problema è molto meno evidente. Abbiamo una BFF scritta in Kotlin che: 1. prende json e lo deserializza in un bean 2. converte il bean in un altro, facendo qualche semplice conversione / arricchendo il bean 3. chiama il servizio Duplichiamo tutto, sia lato REST che lato servizi (nel senso che il vero e proprio oggetto di dominio, o aggregate nel nostro caso, è un altro ancora), ma con le data classes di Kotlin ed i named arguments il codice rimane pochissimo e molto leggibile (così a naso, nel nostro prototipo, direi almeno 50% meno). 2018-01-16 11:51 GMT+01:00 Federico Fissore feder...@fsfe.org [it-torino-java-jug] <it-torino-java-jug@yahoogroups.com>: > > > 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) avevo smesso di scrivere java bean, in > favore di mappe con interfaccia fluente e metodi corti (l'ultima che ho > implementato è https://github.com/ffissore/SteroidMap) > > ho evitato di scrivere centinaia di righe di codice e forse di più. > praticamente facevo in java quello che farei in javascript (non tirate > pomodori, che non è stagione) > > "facevo" appunto, perchè invece dove lavoro ora non funziona così > > federico > > -- ** Think about the environment before printing
