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.
Related
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.
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.
Looking for suggestions for an efficient way to maintain basic audit fields for entities in AppEngine for Java (via objectify). The #PrePersist attribute looks like a good option for various date fields (dateCreated, dateModified, dateDeleted) but I'm also looking to store the ID of the user who created, modified, deleted the entity as well. Is this best left to the data access layer?
If you need to store records with more than just the dates you mention you probably want to create an audit object and use #Embed to store it inside of the objects you're auditing. Then use #PrePersist to update this object. That will give you a consistent audit framework across objects.
IMHO #PrePersist is an ok place to perform this.
You also might want to use objectify's polymorphism - this way you could have a base class containing all audit fields and perform saving. Than all classes needing audit would just extend this base class.
I am developing a new web application with Struts2, Spring and Hibernate as its core building blocks.
We have created POJO classes with respect to hibernate mapping files.There will be some inputs from users which needs to be updated in to the underlying database
e.g registration or updation.
We have few option like creating new POJO/DTO for action classes which will be filled by the Struts2 and than we can transfer them to the service layer where we can convert those DTO to the respected hibernate POJO else we can expose same POJO to struts2 so that the framework can fill them with the user input and we need not to do the work for conversion and creating extra set of classes.
Application will be not big in size and will have a medium size application tag.
My question is what is the best way to transfer this user input to underlying hibernate layer to perform data base specific work.
Thanks in advance
I'd prefer the "DTO" approach in this case since you then can validate the input first and trigger updates only when wanted.
However, you could use detached entities as DTOs and reattach them when you want to create or update them. If you don't want the web part of your application to depend on Hibernate and/or JPA you might need to create another set of classes (unless you don't use a single annotation).
You'll get both answers on this.
With Struts 2 I tend to use normal S2 action properties to gather form values/etc. and use BeanUtils to copy them to the Hibernate objects. The problem with exposing the Hibernate objects to the form, like with ModelDriven etc. is that you need to define whitelists/blacklists if you have columns that should not be set directly by the user. (Or handle the problem in a different way.)
That said, I'm not fundamentally opposed to the idea like a lot of people are, and they're arguably correct.