DAO VS Repository VS Service

In Spring Boot, DAO, Repository and Service are layers in a layered architecture that separates concerns, responsibilities and logic. While they all participate in data handling and business operations, their roles, responsibilities, and usage differ from each other. So, we need to understand DAO vs Repository vs Service in Spring Boot Application for better use. In this topic, we will discuss each layer, compare them, and when and why to use them to maintain clean, maintainable, and scalable Spring Boot applications.

What is the DAO Layer?

DAO is a traditional design pattern that encapsulates the logic for accessing data from a data source (like a database). It is often manually implemented and interacts directly with the database or persistence provider.

Key Features

• Encapsulates low-level persistence logic
• Uses JDBC, Hibernate, or JPA
• Requires manual implementation
• Annotated with @Repository

Example

public interface UserDao {
User findById(Long id);
void save(User user);
}

@Repository
public class UserDaoImpl implements UserDao {
@PersistenceContext
private EntityManager entityManager;

public User findById(Long id) {
return entityManager.find(User.class, id);
}
public void save(User user) {
entityManager.persist(user);
   }
}

What is Repository in Spring Boot?

Repository is a Spring Data abstraction built on top of the DAO pattern. It reduces boilerplate by providing automatic CRUD implementations based on interface definitions.

Key Features

• Uses Spring Data JPA
• Auto-generates methods like save(), findById(), delete(), etc.
• Supports derived query methods (e.g., findByUsername)
• Annotated with @Repository or detected automatically

Example

public interface UserRepository extends JpaRepository<User, Long> {
User findByUsername(String username);
}

Why Use It?

• Reduces boilerplate
• Highly maintainable and readable
• Preferred in modern Spring Boot apps

What is Service in Spring Boot?

Service Layer contains the business logic of your application. It acts as a bridge between the controller (web layer) and the repository/DAO (data layer).

Key Features

• Contains business rules and workflows
• Annotated with @Service
• Calls Repository/DAO methods
• Decouples web and data layers

Example

@Service
public class UserService {
@Autowired
private UserRepository userRepository;

public UserDTO getUserById(Long id) {
User user = userRepository.findById(id)
.orElseThrow(() -> new RuntimeException("User not found"));
return new UserDTO(user.getUsername(), user.getEmail());
   }
}

Layered Architecture in Spring Boot

Spring Boot typically follows a three-layered architecture:

Controller → Service → Repository/DAO → Database

• Controller: Handles HTTP requests/responses.
• Service: Contains business logic.
• Repository/DAO: Manages database interactions.

This separation improves code modularity, testability, and maintenance.

DAO VS Repository VS Service

Feature	DAO	Repository	Service
Purpose	Encapsulate database access logic	Abstraction over DAO with Spring Data	Contains business logic
Layer	Data Access Layer	Data Access Layer	Service Layer
Implementation	Manually implemented	Auto-generated by Spring Data JPA	Manually written
Annotations	@Repository	@Repository or none (auto-detected)	@Service
Use Case	Legacy apps or custom SQL needs	CRUD operations in modern apps	Orchestrating data flows and business logic
Reusability	Often tightly coupled	Highly reusable and testable	Highly reusable and testable
Example Framework	Hibernate, JDBC	Spring Data JPA	Spring Boot core

When to Use DAO, Repository, and Service

Use DAO when

• You’re working with a legacy codebase.
• You need fine-grained control over queries and transactions.
• You’re not using Spring Data JPA.

Use Repository when

• You’re building a modern Spring Boot app.
• You want to leverage auto-generated CRUD methods.
• You prefer cleaner, declarative persistence logic.

Use Service when

• You need to implement business rules, validations, or workflows.
• You want to decouple the web layer from the data layer.
• You need to aggregate data from multiple sources.

Example Architecture Overview

+----------------------+

|   Controller Layer   | ← @RestController

+----------------------+

          ↓

+----------------------+

|    Service Layer     | ← @Service

+----------------------+

          ↓

+----------------------+

| Data Access Layer    | ← @Repository or DAO

+----------------------+

          ↓

+----------------------+

|     Database         |

+----------------------+

Practical Example

UserController.java

@RestController
@RequestMapping("/users")
public class UserController {
@Autowired
private UserService userService;
@GetMapping("/{id}")
public UserDTO getUser(@PathVariable Long id) {
return userService.getUserById(id);
   }
}

UserService.java

@Service
public class UserService {
@Autowired
private UserRepository userRepository;

public UserDTO getUserById(Long id) {
User user = userRepository.findById(id)
.orElseThrow(() -> new RuntimeException("User not found"));
return new UserDTO(user.getUsername(), user.getEmail());
  }
}

UserRepository.java

public interface UserRepository extends JpaRepository<User, Long> {
User findByUsername(String username);
}

Conclusion

In Spring Boot,

✔ DAO is for low-level data access logic (now mostly replaced).
✔ Repository is for clean, Spring Data-based database interactions.
✔ Service is for business logic and orchestration.

Use these layers correctly to build modular, testable, and maintainable applications.
Stick to the Repository + Service pattern for modern apps unless you specifically need DAO for custom logic or legacy integration.
By understanding and applying these concepts, we will write cleaner and more maintainable Spring Boot code.