Can I| use #Repository for DAO layer in spring boot - spring

Can we use #Repository for DAO layer in spring boot ?
What is the difference between #Component and #Repository ?
Which one should we use for DAO layer in Spring boot ?

#Repository is a specialization of #Component whose purpose is to handle DAO. So the answer is yes.
#Repository javadoc states :
Indicates that an annotated class is a "Repository", originally defined by Domain-Driven Design (Evans, 2003) as "a mechanism for encapsulating storage, retrieval, and search behavior which emulates a collection of objects".
Teams implementing traditional Java EE patterns such as "Data Access Object" may also apply this stereotype to DAO classes, though care should be taken to understand the distinction between Data Access Object and DDD-style repositories before doing so. This annotation is a general-purpose stereotype and individual teams may narrow their semantics and use as appropriate.

#Repository is an annotation marker. No difference between #Component and #Repository, spring already can create bean instance from your interface if you extends JpaRepository or other spring repository interfaces
For example:
public interface UserRepository extends JpaRepository<User, BigInteger> {
User findByUsernameOrEmail(String username, String email);
}
For more information please follow the link

Related

Spring #Transactional and #Service

I'm working in a company where JPA #transactional are used within #Component beans. I've always been told that #Transactional should be used inside #Service beans. Does someone could explain spring mechanisms differences between those and what are the best pratctices .. and why
There is no difference.
Also, #Service and #Component are the same. #Service is just a stereotype that developers often use to indicate that the Spring Bean is kind of a Service (maybe in a DDD meaning or not)
First of all, there is no difference.
From the spring javadoc
#Component
Indicates that an annotated class is a "component". Such classes are considered candidates for auto-detection when using annotation-based configuration and classpath scanning.
...
#Transactional
Indicates that an annotated class is a "Service", originally defined by Domain-Driven Design (Evans, 2003) as "an operation offered as an interface that stands alone in the model, with no encapsulated state."
May also indicate that a class is a "Business Service Facade" (in the Core J2EE patterns sense), or something similar. This annotation is a general-purpose stereotype and individual teams may narrow their semantics and use it as appropriate.
This annotation serves as a specialization of #Component, allowing for implementation classes to be autodetected through classpath scanning.
Frankly speaking, they behave in the same way.
By using #Transactional annotation on a public method or class it simply creates a proxy with transaction code for you.
IMO great explanation of #Transactional
Spring Stereotype Annotations

Should I annotate Spring Data Repositories with #Repository [duplicate]

I'm using Spring Data JPA repositories (like MyRepo extends JpaRepository) and it works without #Repository and without #EnableJpaRepositories annotations. Could someone explain why?
Probably you are using Spring Boot.
Spring Data repositories usually extend from the Repository or CrudRepository interfaces. If you use auto-configuration, repositories are searched from the package containing your main configuration class (the one annotated with #EnableAutoConfiguration or #SpringBootApplication) down.
Please check the Spring Boot Reference Documentation (v2.7.2) for more details.
you don't need #Repository to make use of Spring Data JPA.
The Interface extending the CrudRepository or JPARepository would work even without annotating it with #Repository.
The Core reason why you need to have this annotation in place is it makes unchecked exceptions thrown in the DAO layer eligible to be translated into Spring DataAccessException. Which in turn would be easier to work with. This is the important aspect of using #Repository
More details see this -> https://www.youtube.com/watch?v=z2re1MfWtz0&list=PLO0KWyajXMh4fGMvAw1yQ1x7mWayRcmX3&index=8&t=0s
For more information look into these class which is used to auto-configure Spring Data JPA Repositories:
JpaRepositoriesAutoConfigureRegistrar
Docs : http://www.atetric.com/atetric/javadoc/org.springframework.boot/spring-boot-autoconfigure/1.2.0.RELEASE/org/springframework/boot/autoconfigure/data/jpa/JpaRepositoriesAutoConfigureRegistrar.html
#EnableJpaRepositories
private static class EnableJpaRepositoriesConfiguration {
}

What is a spring service annotation? [duplicate]

This question already has answers here:
What's the difference between #Component, #Repository & #Service annotations in Spring?
(31 answers)
Closed 5 years ago.
I understand that #Service is used to mark a class as a business logic class. Why is it useful for spring? I can already use #Component to mark a class as a bean. I understand that #Service is more specific than #Component, but how?
Consider #Component annotation as a Swiss Knife. It can act as cutting knife, as an opener, as a scissor, etc.
Similarly, your Component can act as a Repository, as Business Logic class or as a controller.
Now, #Service is a just one of the versions of #Component, say a knife.
Spring process #Service similar to #Component, since #Service interface itself is annotated with #Component.
From Spring docs.:
#Target(value=TYPE)
#Retention(value=RUNTIME)
#Documented
#Component
public #interface Service
Indicates that an annotated class is a "Service" (e.g. a business
service facade).
Why to differentiate both of them?
To apply the basic rule of programming: Your code should be easily readable.
Yes, you can use #Component annotation everywhere and it will work fine but for the better understanding of the code, it is preferred to use the respective special types of annotations like #Service in our case.
The other benefit is ease of debugging. Once you know the error, you need not hope from one component class to another, checking it time whether that class is service, repository or controller.
#Service, #Controller, #Repository = {#Component + some more special functionality}
Click the below link for more details
What's the difference between #Component, #Repository & #Service annotations in Spring?
The #Component annotation marks a java class as a bean so the
component-scanning mechanism of spring can pick it up and pull it into
the application context. The #Service annotation is also a
specialization of the component annotation. It doesn’t currently
provide any additional behavior over the #Component annotation, but
it’s a good idea to use #Service over #Component in service-layer
classes because it specifies intent better. Additionally, tool support
and additional behavior might rely on it in the future.
The #Service annotation is a specialization of the component annotation. It doesn’t currently provide any additional behavior over the #Component annotation, but it’s a good idea to use #Service over #Component in service-layer classes because it specifies intent better. Additionally, tool support and additional behavior might rely on it in the future.

#Repository in Spring 4

#Repository
public interface userRepository extends JpaRepository<User, Long> {
}
There are many sites showing this way of creating DAO in Spring 4 using JpaRepository. #Repository also creating instance just like #Component, #Service etc. Container internally beans by using new operator while component scan (using #Component scan annotation) of classes having annotation #Component, #Service etc. Then how container create instance for #Repository as shown above, as it is an interface which is purely abstract and we can't create instance for interface using new operator.
Spring will create a SimpleJpaRepository instance for declared Interfaces that extend JpaRepository.
Note: there is much more magic going on. You can add your own queries via #Query to the interface and Repositories also support transaction management. To achieve that the Repository will be wrapped in a proxy which can intercept and dynamically implement its methods.

Is Spring annotation #Controller same as #Service?

Is Spring annotation #Controller same as #Service?
I have idea about #Controller which can be used for URL mapping and invoking business logic.
while #Service used to annotate service class which contains business logic.
Can I use #Controller instead of #Service to annotate Service class?
No, they are pretty different from each other.
Both are different specializations of #Component annotation (in practice, they're two different implementations of the same interface) so both can be discovered by the classpath scanning (if you declare it in your XML configuration)
#Service annotation is used in your service layer and annotates classes that perform service tasks, often you don't use it but in many case you use this annotation to represent a best practice. For example, you could directly call a DAO class to persist an object to your database but this is horrible. It is pretty good to call a service class that calls a DAO. This is a good thing to perform the separation of concerns pattern.
#Controller annotation is an annotation used in Spring MVC framework (the component of Spring Framework used to implement Web Application). The #Controller annotation indicates that a particular class serves the role of a controller. The #Controller annotation acts as a stereotype for the annotated class, indicating its role. The dispatcher scans such annotated classes for mapped methods and detects #RequestMapping annotations.
So looking at the Spring MVC architecture you have a DispatcherServlet class (that you declare in your XML configuration) that represent a front controller that dispatch all the HTTP Request towards the appropriate controller classes (annotated by #Controller). This class perform the business logic (and can call the services) by its method. These classes (or its methods) are typically annotated also with #RequestMapping annotation that specify what HTTP Request is handled by the controller and by its method.
For example:
#Controller
#RequestMapping("/appointments")
public class AppointmentsController {
private final AppointmentBook appointmentBook;
#Autowired
public AppointmentsController(AppointmentBook appointmentBook) {
this.appointmentBook = appointmentBook;
}
#RequestMapping(method = RequestMethod.GET)
public Map<String, Appointment> get() {
return appointmentBook.getAppointmentsForToday();
}
This class is a controller.
This class handles all the HTTP Request toward "/appointments" "folder" and in particular the get method is the method called to handle all the GET HTTP Request toward the folder "/appointments".
I hope that now it is more clear for you.
If you look at the definitions of #Controller, #Service annotations, then you'll find that these are special type of #Component annotation.
#Component
public #interface Service {
….
}
 
#Component
public #interface Controller {
…
}
So what's the difference?
#Controller
The #Controller annotation indicates that a particular class serves the role of a controller. The #Controller annotation acts as a stereotype for the annotated class, indicating its role.
What’s special about #Controller?
You cannot switch this annotation with any other like #Service or #Repository, even though they look same.
The dispatcher scans the classes annotated with #Controller and detects #RequestMapping annotations within them. You can only use #RequestMapping on #Controller annotated classes.
#Service
#Services hold business logic and call method in repository layer.
What’s special about #Service?
Apart from the fact that it is used to indicate that it's holding the business logic, there’s no noticeable specialty that this annotation provides, but who knows, spring may add some additional exceptional in future.
Linked answer: What's the difference between #Component, #Repository & #Service annotations in Spring?
No, #Controller is not the same as #Service, although they both are specializations of #Component, making them both candidates for discovery by classpath scanning. The #Service annotation is used in your service layer, and #Controller is for Spring MVC controllers in your presentation layer. A #Controller typically would have a URL mapping and be triggered by a web request.
#Service vs #Controller
#Service : class is a "Business Service Facade" (in the Core J2EE patterns sense), or something similar.
#Controller : Indicates that an annotated class is a "Controller" (e.g. a web controller).
----------Find Usefull notes on Major Stereotypes
http://docs.spring.io/spring/docs/current/javadoc-api/org/springframework/stereotype/Component.html
#interface Component
#Target(value=TYPE)
#Retention(value=RUNTIME)
#Documented
public #interface Component
Indicates that an annotated class is a component. Such classes are considered as candidates for auto-detection when using annotation-based configuration and classpath scanning.
Other class-level annotations may be considered as identifying a component as well, typically a special kind of component: e.g. the #Repository annotation or AspectJ's #Aspect annotation.
#interface Controller
#Target(value=TYPE)
#Retention(value=RUNTIME)
#Documented
#Component
public #interface Controller
Indicates that an annotated class is a "Controller" (e.g. a web controller).
This annotation serves as a specialization of #Component, allowing for implementation classes to be autodetected through classpath scanning. It is typically used in combination with annotated handler methods based on the RequestMapping annotation.
#interface Service
#Target(value=TYPE)
#Retention(value=RUNTIME)
#Documented
#Component
public #interface Service
Indicates that an annotated class is a "Service", originally defined by Domain-Driven Design (Evans, 2003) as "an operation offered as an interface that stands alone in the model, with no encapsulated state."
May also indicate that a class is a "Business Service Facade" (in the Core J2EE patterns sense), or something similar. This annotation is a general-purpose stereotype and individual teams may narrow their semantics and use as appropriate.
This annotation serves as a specialization of #Component, allowing for implementation classes to be autodetected through classpath scanning.
#interface Repository
#Target(value=TYPE)
#Retention(value=RUNTIME)
#Documented
#Component
public #interface Repository
Indicates that an annotated class is a "Repository", originally defined by Domain-Driven Design (Evans, 2003) as "a mechanism for encapsulating storage, retrieval, and search behavior which emulates a collection of objects".
Teams implementing traditional J2EE patterns such as "Data Access Object" may also apply this stereotype to DAO classes, though care should be taken to understand the distinction between Data Access Object and DDD-style repositories before doing so. This annotation is a general-purpose stereotype and individual teams may narrow their semantics and use as appropriate.
A class thus annotated is eligible for Spring DataAccessException translation when used in conjunction with a PersistenceExceptionTranslationPostProcessor. The annotated class is also clarified as to its role in the overall application architecture for the purpose of tooling, aspects, etc.
As of Spring 2.5, this annotation also serves as a specialization of #Component, allowing for implementation classes to be autodetected through classpath scanning.
I already answered similar question on here Here is the Link
No both are different.
#Service annotation have use for other purpose and #Controller use for other.
Actually Spring #Component, #Service, #Repository and #Controller annotations are used for automatic bean detection using classpath scan in Spring framework, but it
doesn't ,mean that all functionalities are same.
#Service: It indicates annotated class is a Service component in the business layer.
#Controller: Annotated class indicates that it is a controller components, and mainly used at presentation layer.
You can declare a #service as #Controller.
You can NOT declare an #Controller as #Service
#Service
It is regular. You are just declaring class as a Component.
#Controller
It is a little more special than Component.
The dispatcher will search for #RequestMapping here.
So a class annotated with #Controller, will be additionally empowered with declaring URLs through which APIs are called
Controller will handle the navigation between the different views. Your mappings request mappings are handled with the help of controller.
Service interacts directly with the repository where usually the business logic is performed. You can add, delete, remove etc at the service layer
No you can't they are different. When the app was deployed your controller mappings would be borked for example.
Why do you want to anyway, a controller is not a service, and vice versa.
From Spring In Action
As you can see, this class is annotated with #Controller. On its own, #Controller doesn’t do much. Its primary purpose is to identify this class as a component for component scanning. Because HomeController is annotated with #Controller, Spring’s component scanning automatically discovers it and creates an instance of HomeController as a bean in the Spring application context.
In fact, a handful of other annotations (including #Component, #Service, and #Repository) serve a purpose similar to #Controller. You could have just as effectively annotated HomeController with any of those other annotations, and it would have still worked the same. The choice of #Controller is, however, more descriptive of this component’s role in the application.
Both are special form of #Component annotation.
Both #controller and #serviec, share same functionalities of #component annotation along with their own functionalities.
#Controller is a class-level annotation and it marks the class as web request handlers. For further explanation you can refer to this website: https://www.baeldung.com/spring-controller-vs-restcontroller
#Service is also a class-level annotation and it contains a business logic.
For further explanation you can refer to this website: https://www.baeldung.com/spring-component-repository-service

Resources