I am working on a JAX-RS project, with a DAO layer. I am not sure about which architecture to follow.
For example, let's say we have a ProductDAOImpl
class that implements a ProductDAO
interface, and a ProductRS
class as the entrypoint for the products REST service.
Question 1
Where should the ProductDAO
(actually ProductDAOImpl
) instance be created?
Options:
A) In each method of the ProductRS
class that needs access to the product?
B) As a member of the ProductRS
class?
(Can this option introduce data races? Not sure how the container handles the REST services classes - Possibly related to question 2 below.)
Question 2
Should I use annotations for JAX-RS classes, such as @Stateless
?
Question 3
What are the best practices for the architecture and class relationship in a JAX-RS application with a DAO layer and possibly a Service layer?
(Any links to study for this topic are more than welcome.)
Question 4
Should the DAO implementation classes provide static methods? (as seen here)
Implementation specific details
Using Jersey implementation of JAX-RS with Glassfish server and a DAO layer with JDBC access to the data source.
Question 1
I wouldn't create instances explicitly. Usually dependency injection it is used for this reason - inject ProductDAO interface in your ProductRS class.
Question 2 - 3
Some examples related (although not exact) for your technology stack.
Jersey + Spring example: https://www.mkyong.com/webservices/jax-rs/jersey-spring-integration-example/
Jersey + Guice example: http://www.nailedtothex.org/roller/kyle/entry/lean-example-of-tomcat-82
Guice + Hibernate example: http://www.benmccann.com/hibernate-with-jpa-annotations-and-guice/
Jersey + Hibernate + Spring example: http://www.benchresources.net/jersey-2-x-web-service-integrating-with-spring-and-hibernate-orm-framework-using-annotation/
Question 4
There are no static methods in the provided link (Should we always use Asynchronous JAX-RS resources For mobile backend?)
UPDATE
It is recommended to avoid static methods in DAO because of difficult testing. Related discussions: