Do Service and DAO Layers Really Need Interfaces? A Practical Spring Analysis

Why Interfaces May Be Unnecessary with Dependency Injection

When a project uses a DI framework like Spring, you can omit interfaces because the container can inject concrete classes directly.

Common Arguments for Interfaces and Their Flaws

Enabling upper‑layer code (e.g., Controller) to compile before lower‑layer logic is implemented.

Spring’s AOP relies on dynamic proxies, which supposedly require interfaces.

Supporting multiple Service implementations.

All three reasons are weak in typical projects:

1. Most teams develop a full feature end‑to‑end, so defining an interface first adds little value and only increases workload.

2. Spring can use CGLIB proxies, which work without interfaces.

3. Multiple implementations are rare; when needed, other patterns can replace interfaces.

Recommended Top‑Down Development Process

Write Controller logic first, inserting Service calls as needed.

Let the IDE generate the missing Service class and methods, marking them with TODO.

After all classes and methods are stubbed, fill in the business logic based on the TODO placeholders.

This approach improves understanding of the overall workflow.

Handling Multiple Implementations

If you anticipate multiple Service implementations, two structural options exist:

Option 1 – Single Service Package with Multiple Implementations

Controller → Service (interface) → ServiceImpl and ServiceImpl2 in separate packages.

Dao remains unchanged.

This keeps the package layout simple but introduces extra configuration.

Option 2 – Separate Service Modules

Create a new module (e.g., Service2) with its own interface and implementation.

Both modules are injected via configuration, allowing clear separation of old and new logic.

Option 2 offers clearer modular boundaries but adds module‑level complexity.

Combining the Advantages

Separate the interface from its implementation into an independent module:

Controller

Service – Interface module

Dao

Adjust the build configuration to include either ServiceImpl or ServiceImpl2. This allows swapping implementations without changing package structures or DI configuration.

When to Keep Interfaces

If a project truly requires multiple implementations and the number of variants is significant, interfaces remain useful; otherwise, they can be omitted to reduce boilerplate.

Conclusion

The article argues that in Spring‑based projects, interfaces for Service and DAO layers are often unnecessary, especially when development follows a top‑down approach, and provides concrete strategies for managing the rare cases where multiple implementations are needed.