Menu
Recently I have stumbled upon a situation where my new team is heavily using JsonObject for doing rest data interchange. Their view is while using pojo we are binding tightly with the rest service, while jsonObject gives freedom. Also it saves from unnecessary data serialisation at the same time reducing number of classes heavily.
I have some points to encounter them as:
@JsonIgnore
I don't know exactly on the cost of deserialisation, but somehow I have a feeling it shouldn't be much difference.
Can someone help me understand which perspective is way to go ?
Please provide some pros and cons of using POJO and JSONObject.
Thanks
324
POJO classes are used to represent data. POJO Class will contain only default constructor, private data members, and public setter and getter methods for every data member. Setter methods are used to set the value to the variable. Getter methods are used to get the value from the variable.
The name is used to emphasize that a given object is an ordinary Java Object, not a special object. A POJO is usually simple so won't depend on other libraries, interfaces or annotations. This increases the chance that this can be reused in multiple project types (web, desktop, console etc).
A JSONObject constructor can be used to convert an external form JSON text into an internal form whose values can be retrieved with the get and opt methods, or to convert values into a JSON text using the put and toString methods.
In software engineering, a plain old Java object (POJO) is an ordinary Java object, not bound by any special restriction.
I see the following advantages in having pojos
1) Readability - You will not really know the structure of a complex json. writing a simple get will require one to know the structure of the json. Please refer to the "POJOs over JSON Objects" section of my article here -> https://medium.com/tech-tablet/programming-went-wrong-oops-38d83058885
2) Offers Type Checks - We could easily assign a Cat to a Dog and not even know about it till runtime.
3) Feels more object-oriented with Composition & encapsulation - It's easy to understand the designer's perspective with a POJO. A Car which IS-A Vehicle that HAS-A Wheel.
4) You could choose what you wanna deserialize and keep only that in memory - When deserializing the object that we have just received over the network, with a JSON Object, there is no way to choose what has to be deserialized and stored into memory. If you have an object of 1 MB size where only 200 Bytes is your payload, we will end up holding the entire 1 MB object in memory if we don't use POJOs.
5) Allows collection to be used and stream operations on them in a legible way - There is no native support for stream operations in a JsonNode. We will need to use a StreamStupport object which could be avoided.
6) Allows cross framework referencing. With a few annotations, you can choose to map specific fields to a database client - When you use an ORM framework for you database, it's easy to annotate and map entities to the database schema.
7) Naturally supports design patterns
8) Minimalizing non-native dependencies - Why do you have to use a JsonNode or equivalent that does not come by itself in native Java? Especially if it has the above disadvantages.
If you are concerned about the rituals that come with a pojo like having getters, setters etc, take a look at "Lombok". This library will help you create your pojos in a concise way and still reap the above benefits.
On the other hand if you are are dealing with a hard to change legacy API that responds with a dynamically changing response, JsonNode is a quick win candidate.
67
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
