How to find a pattern to keep the same data modeling between a JSON object, a POJO, and JPA?

Navigation
3

To make it easier for me to understand my question, follow the example below:

A POJO: 

public class Person {

    private String name;
    private String location;

}

String JSON: 

String json = {name:"Jose", location:"Eslovenia"};

Serialization: 

Gson gson = new GsonBuilder().create();
Person p = gson.fromJson(json, Person.class);

Insert in database: 

 Session session = HibernateUtil.getSessionFactory().openSession();
 session.beginTransaction();

 session.save(p);
 ...

Note that in several examples there is always a field pattern of both a json object for a java object and a java object for the database fields.

Doubt is not at the code level but rather conceptual:

1 - In the examples with some fields it works ok, but in a real system, is it possible to keep that pattern in the 3 levels (json, java, and bank) with many fields and complexity?

2 - If it is possible to keep working in this way is it considered good programming practice to follow this kind of pattern?

3 - Is there any case that this pattern would be impractical?

4 - Should database modeling reflect in POJO and should POJO serve as the basis for the json object?

Any other consideration aside the questions is also very welcome.

    
asked by anonymous 26.07.2016 / 22:36

2 answers

2

Imagining that this JSON will be used in an API:

  

1 - In the examples with some fields works ok but in one   system, it is possible to maintain this pattern in all three levels (json, java, and   bank) with many more fields and complexity?

Possible everything is :). On small projects, I believe you can even maintain this structure and it will work very well for a small monolithic system, being quite productive with it. But you will soon realize that this will not work with time.

  

2 - If it is possible to maintain, working in this way is considered a   good programming practice follow this kind of pattern?

I do not see problems if this is making your life easier. As I said earlier, for simple cases it will work and it will bring a great gain of time. But if this system tends to grow big and gain complexity, this model will have expiration date.

In the first case that you do not want / can obey this behavior, you will begin to come out of this pattern, and it will stop making sense and bring headaches.

  

3 - Is there any case that this pattern would be impractical?

Citing some examples:

  • Imagine that you have a POJO Person (I think in your case, the POJO is a JPA / Hibernate entity, but let's call POJO) with 15 fields (name, date of birth, gender, ). Among them, 5 are required. Does it make sense for the 15 to always be in your request / response? If you have fields with 100 or even 1000 characters, will you ever need to return them? And if you have sensitive information from the Person (primary key, document, etc.), you will need to control with GONO annotations in POJO not to send them (you may have cases that you would like and others do not). And the list goes on ...
  • If you need to change your POJO (separate a table into two other tables, move fields to another POJO, rename a field, etc), your JSON will change too ... what is the impact of this change on your application which sends / consumes JSON every time this occurs?
  • If you need to make a micro-service available that saves Person to other systems, it is likely that the Pessoa attributes are not optimal for understanding this service for other systems that will communicate with it.
  

4 - Database modeling should reflect in the POJO and the POJO should   serve as the basis for the json object?

The model that is simple and works well, in my view, is:

  • The service that will make this JSON available is represented by a DTO, which will be serialized / deserialized. It will only be used to be populated with required information.
  • The DTO can not access POJO, it would be in a different project. Reason? If you tie your POJO to the DTO you stay hostage to the POJO changes, even to a much lower degree than the one proposed in your question. As I see it, POJO changes should never reflect directly on your DTO.

As a suggestion of organization and without leaving too complex, I think of an organization with three projects:

  • project-api (project-service dependent):
    • Contains: DTOs.
    • Responsibility: Fills and serializes / deserializes the DTO with the information received by service . You can use VOs for this communication with the project-service.
  • project-service (depends on project-domain):
    • Contains: services (for business rules) and VOs.
    • Responsibility: It invokes the search / save / update / remove methods of the project-domain by passing POJO and using VOs to communicate with the api-project.
  • project-domain :
    • Contains: POJOs.
    • Responsibility: save POJO, containing the search / save / update / remove methods in the database.

You can improve this, just an example.

About this naming of VO, POJO, DTO, etc., do not worry, this is not well defined . Just create a pattern for your project by using each nomenclature.

    
29.07.2016 / 04:11
2

I do not see any problems in maintaining this pattern in simpler cases like CRUD, but in more complex models I have used one object representing the query in the database and another to transfer data to the view, so I can create a query that has the best performance possible and I use a DTO to represent the JSON required for communication with the view.

Base modeling should not restrict what you should do in the code, since we generally use relational bases and work with object-oriented languages, we would not take advantage of some functionality as an inheritance if we did.

In practice I have used Dozer to perform the transformation of POJO or VO to DTO, which transfers data from one class to another by convention (fields with the same name) or configuration described in an XML.

    
28.07.2016 / 16:43
Doubt with connection to php database with mysql Error in program execution involving pointers