Do Service and DAO Layers Need Interfaces? When to Use Them in Spring Projects

Recently I saw the question “Do Service and DAO layers really need an interface for every class?” and gave a brief answer of “it depends”. After reviewing projects I work on and reading source code, I found that if a project uses a dependency‑injection framework like Spring, interfaces are often unnecessary.

Reasons Some Developers Use Interfaces

Typical arguments for adding interfaces to Service and DAO layers are:

Allows upper‑level code (e.g., Controllers) to be written before the lower‑level logic is implemented.

Spring’s AOP is based on dynamic proxies, which traditionally require interfaces.

Enables multiple implementations of a Service.

In practice these reasons are weak.

Why the First Reason Falls Short

Writing Controllers before Services can help when different teams develop separate modules, but most projects are organized by functional modules rather than strict layers, so developers usually own the full flow from Controller to DAO and can simply create empty methods as placeholders.

A recommended top‑down coding flow is:

Write Controller logic first, inserting Service calls as needed.

Use IDE auto‑completion to generate the called classes and methods, marking them with TODO.

After all classes and methods exist, fill in the business logic based on the TODOs.

Why the Second Reason Is Not Absolute

Spring’s default AOP uses JDK dynamic proxies, which need interfaces, but you can switch to CGLIB proxies, which work without interfaces.

Why the Third Reason Is Limited

Multiple Service implementations are rarely required; when they are, other techniques (e.g., conditional beans) can replace the need for interfaces.

Project Structure and Interface Implementation

A typical layered project looks like:

Controller

Service

Dao

If you don’t need multiple implementations, the structure works without interfaces.

When multiple implementations are needed, the structure may become:

Controller

Service (interface package)

ServiceImpl (implementation package)

ServiceImpl2 (alternative implementation)

Dao

Two approaches to handle this:

Create a new package under Service for the new logic and configure the bean to inject the desired implementation.

Add a completely new Service module with its own package, ensuring class names differ to avoid conflicts, then configure injection accordingly.

The first method is simpler; the second gives clearer module separation but may introduce unused code.

Drawbacks of Not Using Interfaces

Without interfaces, you lose a strong contract that IDEs can use for code generation and error checking, making multi‑implementation scenarios harder to manage.

If a project truly requires many implementations, interfaces are advisable; otherwise, they can be omitted.

Conclusion

The article argues that the usual reasons for adding interfaces to Service layers are not compelling when using Spring’s dependency injection, and suggests a pragmatic approach: use interfaces only when multiple implementations are needed, otherwise rely on concrete classes and Spring’s flexible proxy mechanisms.