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 ... perché ... / creo una "duplicazione" dello stesso bean soltanto sotto tortura perché ... Personalmente credo che ogni decisione abbia dei pro e dei contro, non sempre sono evidenti subito. La mia inclinazione è quella di avere degli oggetti core del sistema (oggetti "veri" come li hai chiamati, con della logica vera) + una rappresentazione per ogni tipo di boundary (vista da serializzare/deserializzare, entity per il database, dto per colloquiare 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. Ciao, Tatiana пн, 15 янв. 2018 г. в 18:59, bruno bossola [email protected] [it-torino-java-jug] <[email protected]>: > > > 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 passo parametri > (magari un repository) e c'e' della logica "vera" da disegnare. > > Ciao, > > Bruno. > > 2018-01-15 17:35 GMT+00:00 Tatiana Litvinova [email protected] > [it-torino-java-jug] <[email protected]>: > > 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 è insensato? >> >> Preferite mapper automatici tipo dozer o fate a mano (al di là di come e >> dove, comunque a mano)? >> >> Grazie, >> Tatiana >> >> вс, 14 янв. 2018 г.. в 11:23, bruno bossola [email protected] >> [it-torino-java-jug] <[email protected]>: >> > >>> >>> Se il problema e' che da A devo costruire B, allora un metodo in A che >>> si chiama "buildB()": questo per "information expert" (GRASP) >>> <https://en.wikipedia.org/wiki/GRASP_(object-oriented_design)#Information_expert>, >>> e >>> se ci sono cose secondarie da usare nella conversione le passo come >>> parametro. >>> >>> In altri casi dipende... in genere cerco di assegnare la responsabilita' >>> a qualche oggetto che ha senso che ce l'abbia :) >>> Ciao, >>> >>> Bruno >>> >>> >>> 2018-01-12 17:35 GMT+00:00 Federico Fissore [email protected] >>> [it-torino-java-jug] <[email protected]>: >>> >>>> >>>> >>>> Ciao >>>> >>>> domandina del venerdì sera >>>> >>>> Da qualche tempo vedo con crescente frequenza questo tipo di codice >>>> >>>> return ExpenseBuilder.anExpense() >>>> .withId(id) >>>> .withAmount(new BigDecimal(66.6).setScale(2, RoundingMode.CEILING)) >>>> .withDate(new Date()) >>>> .withReason("Something pretty") >>>> .build(); >>>> >>>> Viene da un test, quindi i dati sono hardcodati. Altrimenti vengono >>>> presi da un altro bean via getter, oppure quest altro bean offre lui un >>>> metodo che restituisce un builder pre-popolato >>>> >>>> Anche voi siete abituati a fare così quando dovete passare dati da una >>>> DTO a un altro? Se no, come fate? >>>> >>>> ciao >>>> >>>> federico >>>> >>> >>> >
