dimanche 17 septembre 2017

Best way to handle repetitive data structures that serve the different purposes

I design the core application that has

  • a database model with Hibernate entity classes a REST incoming
  • interface with Jackson serialization, so mapping classes for all messages
  • a REST outgoing interface that has many similarities with the input but also few differences, so mapping classes again.

I initially though to define a single set of Java classes with one class serving all three purposes, but I have some (potentially wrong) bad feeling about this. Database entity is database entity, it has some housekeeping fields (date created, date modified, reviewing flags for instance) that REST messages do not have, and the outgoing messages must match the third party API with not many, but some specific requirements like including they specific "class name" as one of the JSON fields, and some simple but required custom code must be included to convert between formats.

Still, there really many cases when I am just copying identically named fields (it is the Address, so city, street, house number, country, zip code present in all three variants) between data structures. With many fields present, and be careful not miss any, also feels like I am doing something wrong.

  • Should I try to redefine single set of data structures that have all fields mentioned only once but need multiple annotations from different frameworks (Jackson, Hibernate), fields that only one database or only REST messages use (ok null in alternative case)?

  • Or should I agree with myself that data structure serves a single purpose and having these duplicate fields in classes serving for different purposes is ok?

  • Or should I attempt to use reflection for copying the identically name fields between the structures? I have been told once that reflection is something that only frameworks should use, better to avoid in the normal production code.

  • Finally, maybe some framework exist to address the problem of slightly different, mostly similar Java classes that are data structures for co-operating frameworks?

Aucun commentaire:

Enregistrer un commentaire