I have a use case where I have one dto class that has all the data retrieved from a db call. I need to create different json formats using information from that class.
What is the best way to do this?.Also is there a way to do this with out making a code change everytime a new json format is needed ,something like storing the different json schemas in a persistence layer and then
do the mapping dynamically ?
I provide below my simple thoughts. Suppose you have a dto class say EmpDto which has data in relation to your database table model. If you want to create a json in way different way, then you create a separate object model like EmpJsonBean and annotate the Json annotations from Jackson framework. You have to populate the EmpJsonBean by taking required data from the EmpDto class. This way you can do it.
If you think of a design pattern so that you can have minimal impact, I would suggest for Adapter design pattern so that you can have a different json structure based upon the business need.
Related
I have a JSON which I am using as a fabricated data to create a POJO using GSON. This is expected data for my tests. Next, I have data from the cucumber feature file which would override some of the fields in the already created POJO i.e. update expected data object. I was wondering if anybody has done this earlier or is aware of pattern which I can use to achieve this. In terms of approaches, in was wondering if makes more sense to create an updated json first from both the data sources or to create POJO from the first JSON first and then apply mutation.
I have found a way around - using Apache Velocity template instead of vanilla json files simplifies the implementation and provides flexibility.
I have a project where I need to store Users on database. I'm using Hibernate and in some part of module also Spring Data JPA experimentally.
I have a REST endpoint for register customer and I'm receiving there UserDTO object. After that in other service I need to convert it to UserEntity and save in database.
Now I created user settings page where I need to display some information about logged user. I don't want to sent UserDTO object because there is to much data so I need to create one more DTO class and Converter class. I feel it's a little bit tricky because every time when I wan to store or receive some specific data, I need to create new DTO and converter class so I have a lot of DTOs and Converters in my project. When I will need to change something on my Entity class, probably I will need also change a lot of converters.
Is this correct way or do you have any better solution for that?
You can use projection queries to create your DTO-s without converters.
Here is a short example with explanation: JPA - Basic Projections
Sometimes i use jsonschema2pojo to convert some json into a java object, but according with these definitions I always be confused if it is a VO or a DTO. Im sure that isnt an entity, but I dont know how to classify it correctly.
The purpose of the use, is just to get a json in an object. After that, i manipulate these data over the app.
Technically, it's a DTO until you add additional business logic into the class rather than simply the JSON serialization annotations.
The reason I say so is that it's responsible for both transfer and deserialization of a JSON object
I would say that a DTO is a POJO that is setup for the exclusive purpose of being transmitted to and from a datasource. So I would say that if you plan on using the POJO just for transmitting to and from a datasource, then I would call it a DTO. That would let me know what its purpose is for. If the POJO is going to be used for other things beyond just transmitting to and from a datasource, than I would call it a POJO.
Typically I do not see these terms used much anymore. Now I just see POJO and they typically go into a package with the name "model" or "domain". If I see these packages in a project, I know these are POJO's that can be used for business logic or transmitting.
Why its probably not a VO: VO's are small objects, like coordinates, or money. They are immutable and do not contain many fields. So not really something with multiple fields that you would require JSONshema2pojo. Though when parsing a large JSON, JSONschema2pojo might create many little classes that fit this definition.
EDIT: This is all subjective. And only providing an opinion here.
How to convert from json into java objects data and save into database? As I understand the only one way is using DTO? Or I'm wrong?
There is application which returns something like "dump" of database. My aim is to deserialize it and save into database. The problems: in some "object" fields there are ids, there are some exceptions regarding constraints during saving into database.
You need to use google Gson Api, following links show how-tos:
http://www.mkyong.com/java/how-do-convert-java-object-to-from-json-format-gson-api/
Make sure DTO implements Serializable interface before persisting object into database... i would rather serialize on file system and store path into database because i do not like storing in CLOB or BLOB columns... too expensive queries.
Another option is to use Jackson, some examples could be found here. We use it in production for almost two years and find it powerful and handy.
Am having a registration form which has multiple pages. So, I am mapping one page to one pojo. Finally, when I processing with database, I want to make it as single pojo to commit. Any idea to simplify this model.
Thanks :)
You can create a wrapper POJO which holds your other POJO's with additional helper methods in the master POJO.
What is wrong with sending multiple POJOs to your service level to commit to the database. Koekiebox's suggestion of a wrapper POJO will work, but also will add another place to make changes to if you add or remove POJOs.
If the data truly belongs together why not increase the number of fields in your POJO and use just one for your form and database.