1

I'm building a back end service for mobile clients.

The requirement is that the mobile clients will pass me a token, I'll use that token to talk to other systems (behind the company firewall) in my company, and return to the user some information.

Here's a typical scenario:

A mobile client asks for some customer data and makes a call with the customers token. I use the token against the customer database system and get back the customer details. I then return the data (removing some fields that are not relevent )to the mobile client.

All data between systems (me, mobile client, customer database) use JSon.

The question is whether I should work with JSon objects throught my code or try and use POJOs?

Right now, I only need to remove some fields from the customer database before returning to the client.

The future may require more involved transformations but I can't be sure that will happen or the nature of the transformations.

Thanks

Improve this question
7

It's usually a good idea to separate the serialization method (JSON) from your business logic so that if in the future you decide to use some other type of serialization, you can do so without affecting the business logic.

Jackson is probably the most popular open-source library for JSON serialization/deserialization in Java.

In the situation where some amount of transformation is needed between the data received from your customer database and what you actually return to the caller, I usually create a separate DTO (data-transfer object) class that contains only the fields to be serialized.

On the other hand, if you always need to remove the same fields from the customer data before transmittal and don't mind putting serialization-specific annotations on your POJOs, you can use Jackson's @JsonIgnore (or similar) on those fields and skip the DTO.

Improve this answer
2

I'd go for the simplest and easiest solution which will cover your current requirement.

As you mentioned all you need is to remove couple of fields, json manipulation is enough and it's very simple.

In future, as you believe if it comes to more complex transformations (which are not easy to do with json manipulation) you can easily add DTOs in middle and do the transformations. Since you are getting json and sending back json adding DTOs won't affect any of the external systems.

Improve this answer
0

Its a classic tradeoff Performance + ease of use vs. scalability and flexability.

POJOs are highly perfomant and very easy to use in a Java program. BUT they are restricted to a single VM. You cannot pass a POJO to another VM or another server or another process not implemented in Java. To pass the POJO to a Java program in another VM you need to serialize the POJO and de-serialize it at the receiving process. The default Java serialize methods have historically been very dependent on the version of Java used.

JSON formatted messages can be passed between processes, between servers, and can be easily read by Java programs but also Javascript, php, python C, C++ etc. etc.

Other benefits of using a JSON (or XML :-) ) include ease of debugging ( you can just read the message ) and ease of testing (its trivial to create store and copy JSON messages for use in a testing framework).

Improve this answer
2
  • 1
    "The default Java serialize methods have historically been very dependent on the version of Java used." - really? I've been using Java serialisation on & off since version 1.1 was released and have never had a problem (as long as I've declared my own version id in my classes). What compatibility issues have you seen? – Jules Feb 2 '15 at 7:41
  • You already have a way to transmit data to another system: JSON. Saying a POJO is "restricted to a single VM" is just silly when we're already starting with a JSON object that we unmarshall. At this point, the POJO has all the benefits of JSON and also the ease of use within Java. – Azuaron Aug 26 '16 at 17:18
0

I'm in agreement on simplest approach is generally the best and for me JSON manipulation win out hands down in this situation.

The important bit of the question is '(removing some fields that are not relevant ) to the mobile client'

So from what I understand there is more than one mobile client variant and for each different json fields are selected from the source customer data json.

Using the DTO approach, I would first have to marshall the source customer data JSON to a DTO, then if I had 4 mobile clients then I would need 4 DTO's and multiple method for setting the attributes on each Type of DTO.

Using the JSONObject approach, I would have something like:

JSONObject sourceCustomerData = JSONObject.fromObject(httpResponseInputStream)

and would pass the sourceCustomerData to a method to return the JSON suitable to individual mobile client something like: 

JSONObject customerDataClientX = getRequiredJson(requiredJsonFeildsForMobileClientA, sourceCustomerData)

where requiredJsonFeildsForMobileClientA is list of required JSON fields. Therefore for each mobile client a different list of required JSON fields can be passed in.

DTO PROS - Straight forward and verbose code POJO's. - Suitable for more complex transformations. - Easily testable.

DTO CONS - DTO's are models held in code, they cannot changed without manipulating code. - More code as DTO and there population code are directly related to the number of mobile client variants.

JSONObject PROS
- Straight forward code. - Easily testable, it's a function on external factors. - Less code as one shoe fits all, not directly related to the number of mobile client variants
- There is no model held in code, the list of JSON fields for each mobile client can be held in configuration externally.

JSONObject CONS
- Not suitable for more complex transformations. - JSONObject requires navigation JSON model, not so nice to ready or write.

In future, as more complex transformations are required we can add then in and even consider moving to a DTO’s based model if it makes the task easier.

Improve this answer
6
  • 1
    Once the move to more complex transformations happens, you'll be stuck with some code using JSon logic and others with POJOs. I probably won't have time to go back and make it consistent across the board. A POJO based model makes more sense as the overhead is minimal and is flexible for the future. – FinalFive Feb 2 '15 at 11:10
  • Also, the JSon based logic solution is optimised for field removal - not something I would like to 'bake' into the design. Also, a POJO solution can be done with 1 DTO and 4 POJOs, not only 4 DTOs. – FinalFive Feb 2 '15 at 11:14
  • I disagree that the JSon solution produces easy to read code. Putting aside that the quality of readability is subjective and depedendent on the quality of your developers, its also tied to Jackson rather than vanilla Java. – FinalFive Feb 2 '15 at 11:16
  • You code for what we know now not the future, as you don't no the nature of transformations that will be required. I think's you are splitting hairs here '4 POJOs, not only 4 DTOs' as my intent was to show the relationship between mobile client and the number of objects. – Narinder Chana Feb 2 '15 at 13:33
  • I normally assume that individual are well versed in there subject area and differ the below issues as they largely dependent on individuals experience and organisation culture. 'Quality of readability is subjective and dependent on the quality of your developers and the time issue (probably won't have time)' Yes my example uses Jackson rather than vanilla Java and so do the DTO approaches suggest. How do you plan on marshalling to DTO ? – Narinder Chana Feb 2 '15 at 13:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.