0

I want to decouple my code from having many different POJOs that copy the data between multiple levels of abstraction. Is there a way to work with the data without a POJO?

Chap
  • 2,776
  • 24
  • 31

1 Answers1

0

You can use ObjectMapper to convert JSON to HashMap which will also support nested objects. Then it is up to your application/data model to know the type of the primitive values to extract them.

    ObjectMapper objectMapper = new ObjectMapper();
    HashMap<String, Object> map1 = new HashMap<>();
    HashMap<String, Object> map2 = new HashMap<>();
    map2.put("age", 11);
    map1.put("person", map2);

    String output = objectMapper.writeValueAsString(map1);

    map1 = objectMapper.readValue(output, map1.getClass());

    System.out.println(map1);

Output:

{person={age=11}}

Chap
  • 2,776
  • 24
  • 31
  • Care to elaborate? – Chap Feb 23 '18 at 19:16
  • You need certain level of abstraction about the domain of your business. If you have a Person, a Client, a Company, whatever, you should have a class representing this concept. It is the base of object-oriented design and OO languages. Now, if you are tired of POJOs and Data Transfer Objects (DTOs), and mapping from one to another, etc, I can completely understand your point. But how would you do to update a balance and do the propert checkings and update other objects that represent your business domain if you only have maps? – fps Feb 23 '18 at 19:20
  • I think if I gave more context you and I would be on the same page. We have a lot of independent-consistent teams that own their own libraries/responsibilities. Those independent teams might use a shared domain model and need to change it, which will affect other teams. This is a hassle and costly for us. – Chap Feb 23 '18 at 19:44
  • I disagree. I would let each team handle its own API, its own domain model, its own database, its own libraries and even its own language. Use REST APIs to expose services and REST clients to consume them. Let every team evolve independently. That, only to start... Then you might need queues, reporting databases, analytics, monitoring, centralized logging, and if you also need to expose public and uniform services developed by different teams you might also need to use a public API and then route these public services to their respective endpoints. – fps Feb 23 '18 at 20:10
  • Well, looks like I'm not going to convince you, nor do I have value in doing so. You're are right, in general, yes. – Chap Feb 23 '18 at 23:55
  • you won't convince me, but there's no absolute truth either. I just have an opinion, you've got yours, and it's ok. Cheers! – fps Feb 23 '18 at 23:57