Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am using #NamedQueries but not sure what is the best way to use it.
Use it above entity class
Use it above DAO class
Create One NamedQueriesFactory class which will have centralized named queries for all Entity
Any other better way.
i good way would be to put all of them in an xml file which is used a lot. this externalizes your queries and gives you the freedom of just sending over this xml file to some DBA for easier analysis later on.
2 (Dao) and 3 (factory class) are not real options, assuming that those are not also entities, because according documentation:
The NamedQueries annotation can be applied to an entity or mapped
superclass.
That leaves as with 1 (entity) and 4 (mapped superclass). I would locate queries by return type and/or main entity accessed in query. Because mapped superclass cannot be returned from the JPQL queries, answer would be 1 (entity).
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 months ago.
Improve this question
I have always used a double bond in entities.
For example, we have 2 entities "basket" and "product"
In both entities, I put the annotations #ManyToMany (or #ManyToOne and #OneToMany, depending on the logic)
On the new project, I see that the annotations #OneToMany, #ManyToMany can only stand for one entity.
Can anyone explain this is the right approach or the opposite is extremely wrong.
In all the books nothing is said about this, everywhere communication is maintained from 2 sides.
Is it possible that this is done for optimization so that the "product" does not receive information about the "basket" ?
Let me restate my question.
Are there any advantages (optimization or architectural approach) or disadvantages. Is it worth avoiding two-way relationship in the future, so that Hibernate doesn't load unnecessarily?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I have a simple POJO class with few fields. This POJO serves the role of settings and it is passed to one method which actually executes some logic. Fields from this POJO are taken from the app.properties and they will not change.
What is a better pratice?
Create this POJO every time we want to call the method which needs it.
Make it a singleton bean, create it once and then autowire it?
Spring Boot provides the #ConfigurationProperties mechanism specifically to automate this for you. In general, it's best to avoid direct dependencies on MyServiceProperties and to do the injection in an #Bean method, but the MyServiceProperties instance is available as a context bean.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
While working on a Java web application I was wondering if my model layer was written as it should be. For instance, let's say we have a table USER in our SQL database which consists of 15 columns. Now, when we SELECT all of the columns with SQL we map it to a Java class, serialize via JSON and send it via network to some View and show it on screen.
In a second scenario, we want to select only 2 columns on screen so we do SELECT c1,c2 FROM USER. Thats where my question comes in... am I supposed to map those columns to a same Java model class? Or should i create a new mapper and class to fit it? Both of the approaches seem to have drawbacks, separate class for each query is more work, but it makes sure you always know what data it contains, rather than checking for nulls or working with optionals, also it prevents you from mapping columns you actually don't need.
What is your opinion? Thanks a lot!
Technically you could reuse the same User class for full 15-attribute as well as partial 2-attribute entity. But that will come with a price. Every time you'll see an instance of User class in the code your will have to think if it's the full entity or the partial? Which fields may or may not be null? This will make it much harder to reason about code.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
In JAX-RS there is an option to define a custom entity provider(message body workers or message body readers and writers) so that you can map a java bean to MIME type (say application/myBean).
Are there any scenario where one would need it?
One reason for defining custom Media Types is defining tighter contracts. For instance using the header Accept: application/vnd.com.example.customer+xml defines on protocol-level that a list of orders won't be accepted. This is not possible with using application/xml.
If you want to use custom Media Types you need custom providers for serialization.
There is a long going debate if this is a good idea or not.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I simply want to know what is the benefit of using Dozer in project. Here I am really confuse How to use ? and Why I use ? Please help me. I want to map my entity classes to Dto classes and want data flow on my gui through dto classes. And when I saved any data from Gui to DB then I want to convert my Dto Class to Dao Class.
Dozer is about mapping a Java Bean to another Java Bean for some field based value propagation and it is all about in memory objects.
While Hibernate is about mapping POJO (Domain objects) to a relational database.
So as you can see, they are not apparentely related one to the other, and any need to use both of them should be upon a personal choice.
As your question has been edited:
A basic conceptual architecture should be to map your Entities (Domain Objects - you did call it dao classes) through Hibernate to a database.
Then those Entities can be mapped to some Java Beans (which you did call dto classes) using Dozer.