In the repository layer I define normal data operations such as inserting, finding and so on. I am using Spring and I have the #Repository annotation above the class. Is it bad to use this class directly in the #Controller class for instance? Should all repositories always have a service layer that just delegate to the repository layer?
It totally depends on your choice. In Spring Roo, you don't just skip the Repository or Service layer, but use a Rich Domain Model where you have the data access logic in the domain itself. Frameworks like Groovy on Grails use a single Repository layer. So i think its OK to use it directly in the Controller.
I similarly asked what use are EJBs? An answer said this:
your [service layer] typically orchestrates application of business logic but more often than not does not actually perform it, it is usually a very thin wrapper.
The service-layer methods can define the operations that are transactions, and which therefore have annotations to get AOP transaction support added automatically for you. See also an answer to a related question, which says:
Spring's idiom would recommend having a service interface that knows about units of work and a persistence interface that deals with relational databases. The methods in the service interface should map closely to your use cases. The service implementation knows about all the model and persistence packages and classes it needs to accomplish the goals of the use case.
Related
I wonder what the "big advantage" of a one-to-one relationship Spring Repository is over the EntityManager (persistencecontext) and Transactionmanager (transaction demarcation) (and/or Hibernate. I don't know how they work together exactly in JPA).
Can you explain the advantage of Repository?
It seems very rigid because you have to extend the repository interface for every Aggregate in a Microservice environment at least. I don't know if you have to do this for simple #Entitys too.
Basically, we use a Repository to perform CRUD operations, and it establishes a connection between the program and database to retrieve data, and call it into the service environment to perform some functions, that's the reason why extends the repository in the service and #Repository is the indication that it is a repository.
In the context of a recent Spring Boot app (v. 2.7.0), there are a number of options for where the #Transactional annotation is applied
Controller or Service?
Almost universally it seems that service is recommended, but it's not entirely clear why.
Implementation class or interface?
Assuming we choose to apply the annotation to our services and those services implement an interface, should we annotate the service interface or the implementation class?
In older versions of the Spring docs, it was recommended to annotate the class
Spring recommends that you only annotate concrete classes (and methods of concrete classes) with the #Transactional annotation, as opposed to annotating interfaces. You certainly can place the #Transactional annotation on an interface (or an interface method), but this works only as you would expect it to if you are using interface-based proxies. The fact that Java annotations are not inherited from interfaces means that if you are using class-based proxies (proxy-target-class="true") or the weaving-based aspect (mode="aspectj"), then the transaction settings are not recognized by the proxying and weaving infrastructure, and the object will not be wrapped in a transactional proxy, which would be decidedly bad.
But this advice does not appear in the 5.2.X version of the docs, so I'm wondering if it still applies? Based on my testing it seems that applying the #Transactional annotation to interfaces does work in a Spring Boot app with the default proxying behaviour.
#Transactional is most commonly used at service level, though there is nothing stopping you from making your controller methods transactional. It really depends on how you structure your application.
IMHO making your service layer transactional is a better approach. It is typically at this level that you might be calling other persistence methods (DAOs, repositories, etc). There could be reads/writes across multiple tables, so it makes the service layer a good place to define transaction boundaries.
There are three types of classes:
Handler
Service
DAO
A handler handles an incoming command an calls a services. The services does caching and calls other services or a DAO. Services and DAOs are singletons.
Is there a way to create a custom warning if a DAO is used in one of the handlers?
You could try playing with some custom checkstyle rules but... you should rather try to it properly ;)
Create 3 modules (projects in Eclipse). Let Handlers know only about the Services (add a proper dependency to Handlers project) and let Serices know about DAOs (add a DAO project to Services dependencies). This way you will never make a mistake :]
I have a Java EE 6 web application that offers it's data via a JAX-RS REST web service.
The entities are annotated with the JPA annotations as well as with the javax.xml.bind JAX annotations.
My aim is to assemble a client-jar out of my web-app project that contains the JAX-RS annotated "DTO" classes to be used for JAX unmarshalling in clients of my web-app.
Putting the raw entities in the client jar is not an option because of the JPA annotations, which would lead to bogus dependencies for the client.
Is there a way for doing this without writing the JAX-RS classes twice, for the web-app and the clients?
I thought of annotation processing and killing all JPA annotations in the entities, that's quite techy, but not very handy.
My second idea is to extract an interface of the needed getters/setters of the entities. The question here is how to handle the JAX annotations that are placed at the class members and at the getters.
Both ways seem to work somehow. But is there a general purpose solution for that task?
Hint: yes, i'm aware of the way to expose the JPA-Entities directly via rest and its coupling drawbacks to evolution etc =)
You could supply the JPA metadata via XML (http://java.sun.com/xml/ns/persistence/orm_2_0.xsd) instead of annotations. This would give you the mapping without the class path dependency.
http://java.dzone.com/articles/persisting-entity-classes
I'm starting to program in Java (with the Spring Framework) and finding myself confused about the difference between DAOs and Spring's Beans. Do they serve to the same purpose?
DAO == Data Access Object. It's one way to write a persistence layer.
Spring can manage DAO beans and lots of other kinds, like message-driven beans, services, web controllers, and anything else you can encapsulate into a bean.
Spring has three parts:
Inversion of Control (IOC). Think of Spring as a big factory for creating and managing beans.
Aspect-oriented programming (AOP). This is how Spring manages cross cutting concerns like logging, transactions, proxying, remoting, and other activities that otherwise would be littered throughout your application.
Framework code, like the persistence templates for JDBC, Hibernate, TopLink, etc.; remoting; web MVC; etc. They write better code than we do - you get to just use it.
DAOs are a pattern concept (http://www.oracle.com/technetwork/java/dataaccessobject-138824.html).
Spring Beans are class instances managed by Spring.
Of course you can use Spring IOC to implement an application using DAOs.
DAOs are meant to abstract away how the application constructs a data object. More specifically, you can have an interface UserDAO and implement it as a UserHibernateDAO, UserIbatisDAO, UserFileDAO and have them return data in a single format from different sources.
Duffymo explained Spring.