I have the following scenario:
A JAX-RS Webservice that is responsable for the business logic and database interactions.
A webapp that will be used by the end users.
A webapp that will be used by administrators.
My problem is that I want to reuse the entities from the webservice on the other apps, but it is highly wrapped with frameworks like JPA, JAX-RS, CDI, among others... So I am having a hard time to isolate them. What I want is to know the best workaround and why should I use it instead of others.
Maybe DTO is the way to go (with support from some object mapper library like Dozer)
Please take a look at following article for more details: http://zezutom.blogspot.com/2012/02/thoughts-on-data-transfer-objects.html
Write you entity objects as Plain Old Java Objects (POJOs), with proper constructors, setters, etc. Apply the annotations that allow the JPA to persist them and do the object to relational mapping in such a way that, if those annotations were all stripped away you could still create and manipulate those objects fully, using the public methods of the class. It can be helpful if you create the POJO first, then add the annotations afterwards.
As the POJOs stand alone they are not at all part of your repository layer. You can use them without using the JPA at all.
Related
I'm working on a new project, using concepts like clean architecture, protecting my model and business rules from external dependencies and frameworks. Also, I prefer not to use traditional ORM libraries (like JPA/Hibernate) and have choose to use plain jdbc (through spring jdbctemplate).
It was going pretty well, but I'm getting tired of write 20x almost the same query for all my domain classes on a basic crud reposity. So, I take a look at Spring Data JDBC, but it appears that it's necessary to add annotations on my domain classes to make it work properly. I really don't want to do that, first because I want to make my domain cleaner as possible from any dependencies, and second because this is one of the (many) things I really dislike on JPA.
I was wondering that, the repository needs only 2 things: a rowmapper definition and the PK definition (and both could be defined at the repository itself) avoiding the complete use of annotations.
So, my question is there any way to use Spring Data JDBC without annotations?
No, there is no easy way to use Spring Data JDBC (https://spring.io/projects/spring-data-jdbc).
What you could do is to replace those classes that do the annotation interpretation (RelationalPersistentEntityImpl, and BasicRelationalPersistentProperty) and replace them with something that gets the information from elsewhere.
There is a different framework wich might fit the bill which is also named Spring Data JDBC 🤷♀️ https://github.com/nurkiewicz/spring-data-jdbc-repository
It seems pretty close to what you are looking for but it has its last commit 6 years ago and is archived on Github.
I'm working on a new project, using concepts like clean architecture, protecting my model and business rules from external dependencies and frameworks. Also, I prefer not to use traditional ORM libraries (like JPA/Hibernate) and have choose to use plain jdbc (through spring jdbctemplate).
It was going pretty well, but I'm getting tired of write 20x almost the same query for all my domain classes on a basic crud reposity. So, I take a look at Spring Data JDBC, but it appears that it's necessary to add annotations on my domain classes to make it work properly. I really don't want to do that, first because I want to make my domain cleaner as possible from any dependencies, and second because this is one of the (many) things I really dislike on JPA.
I was wondering that, the repository needs only 2 things: a rowmapper definition and the PK definition (and both could be defined at the repository itself) avoiding the complete use of annotations.
So, my question is there any way to use Spring Data JDBC without annotations?
No, there is no easy way to use Spring Data JDBC (https://spring.io/projects/spring-data-jdbc).
What you could do is to replace those classes that do the annotation interpretation (RelationalPersistentEntityImpl, and BasicRelationalPersistentProperty) and replace them with something that gets the information from elsewhere.
There is a different framework wich might fit the bill which is also named Spring Data JDBC 🤷♀️ https://github.com/nurkiewicz/spring-data-jdbc-repository
It seems pretty close to what you are looking for but it has its last commit 6 years ago and is archived on Github.
I am developing a spring restful application that uses hibernate. I am coming across scenarios where i had to place jackson json annotations on entity getters. Ex: One to Many mappings.
Is it a good idea to place jackson json annotations on hibernate entities? Or should i go with DTO pattern to pass data that is just needed by UI? I may end up creating a DTO for every entity.
Below is the application architecture. Common is at root level. DAO has dependency on Common and so on.
Common <- DAO <- Services <- Web
DAO has entities
Services or Web can have DTO's
Please let me know your thoughts or suggestions.
Disclaimer: I am speaking from opinion and experience here
Separate dto and entities are common practice. What you choose to do really depends on it's use. One of the drawbacks of adding DTO annotations on your data model entities is versioning. Versioning becomes hard when your data model is tied to your contract. If your webservice is only used by a consumer you own and its deploy schedule is the same then it's probably not worth separating dto/entities. If you don't need versioning and you mostly have CRUD web services then you may want to look into spring data rest.
If you arn't so lucky, and have multiple consumers, then you may want to think through a few version breaking changes and how you will handle it. This will help you see the value in separating the data and contract.
Well I have recently started reading up on Hibernate so my knowledge is very raw.
I read somewhere that you should not expose your hibernate pojo classes directly on your application rather you should create classes which represents Pojo classes on your application. It's like custom classes which use only some or all of the fields of the Pojo classes.
Can someone put some light onto this as to how in an application we can stop the over exposure of Pojos or what is the correct way of using Pojos and custom classes which are returned from the server.
Better you right your own POJOs classes with required fields... And also write translators to translate data from hibernate POJOS to you Pojos.
Note:- If you are evaluating Hibernate for something, have a look on JOOQ.....
Tomorrow is a world with out ORMss........
http://www.jooq.org/doc/3.6/manual-single-page/
In general, I'd say it depends on your needs, but if you want to do it right, I suggest you have create custom classes for your DTOs that contain just the information you need. I have written an article about why using entities might lead to problems and how you can implement DTOs with Blaze-Persistence Entity Views to solve your problems. That might help you a bit to understand the implications.
In a complete Java EE application that's clustered is the DTO pattern still a valid option? The application in question uses EJBs Hibernate and Struts with Spring etc. Is there anything wrong with transferring domain objects in such a scenario?
EDIT: Just to clarify my question, with modern day resources and improvements in Java EE is there a reason not to just use domain objects? If there is not then isn't DTO pattern sort of fading out and shouldn't be used in new applications?
Is not deprecated. It depends on the application architecture if the DTO pattern should be used or not. For example, when you develop Web Services (using JAX-WS or JAX-RS), you should send DTO's over your web methods so a C# or Python client application may consume it, and your web method should not return an object which class has Hibernate annotations, remember than in other languages the Entity won´t be created with those annotations or other business logic inside.
EDIT (Based in your comment): That depends on the software architecture. For example, I'm working on a SOA project and we use DTO's for the Services Layer and the Presentation Layer. More deeper inside, we even use DTO's to handle database communication inside the services, we use only SP's to communicate with DB, so no Hibernate or any other ORM tools can work there, we could use Spring DAO and that framework uses DTO's too. You can find lots of DTO pattern in many applications nowadays.
More info that would be great for this question:
Difference between DTO, VO, POJO, JavaBeans? (where basically, any DTO is a POJO).
Core J2EE Patterns - Transfer Object
EDIT 2: Another source of information that will explain the main reason for using DTO's design, explained by Martin Fowler
LocalDTO
Conclusion: DTO's are not an anti pattern. DTO's are meant to be used only when you need to pass data from one subsystem to another and they don't have a default or standar way to communicate.
It is a very useful pattern in Java EE.
I use a DTO to transfer related entity objects from EJB beans to the UI layer. The entity objects are fetched from DB in one transaction (see TransactionAttributeType.REQUIRED) and stored in the DTO object. The DTO is consumed in the UI layer.
A pattern is pure design. There is no "deprecation" of pattern, but less usage over time (or over-usage).
Personally, I don't see why not to use DTOs.
For example - at oVirt open source project we have entities representing business logic entities in the domain of Virtualization.
These entities should be either annotated by Hibernate annotations (actually, they are today, as we started working on hibernate POCs) and serve as the DTOs , and then have clean from annotations objects that will mapped to them (let's say, using dozer framework) and used by client
(I don't like have at client side code with unnecessary annotations), or the entities should serve as the client objects (value objects) passed to the client and we should have other classes serve as the DTO entities
The minus in the above approach is that you might have 2 parallel class diagrams - one for DTOs and one for value objects (that are used by clients) - but , in many cases in design , there is a trade-off.
You must understand the advantages and disadvantages and pick what is best for you (In our case, since the client side is GWT, it will be easier for us to go for separation to two class hierarchies, one that is DTO/server side and can be also annotated with more server side only annotations, and the other sent to the GWT client code).