Do You Really Need Interfaces for Service and DAO Layers in Spring?

Reasons Not to Use Interfaces

Using a dependency injection framework like Spring means you can often skip defining interfaces for Service and DAO classes.

Common arguments for adding interfaces are:

Allows writing upper‑layer code (e.g., Controller) before lower‑layer logic is implemented.

Spring’s default AOP uses dynamic proxies, which require interfaces.

Enables multiple implementations of a Service.

These reasons are not convincing.

First Reason

The idea of coding against an interface to decouple layers works when different teams develop separate modules, but most projects organize work by functional modules, not strict layers. In a typical backend, a developer handles the whole flow from Controller to DAO, so defining an interface for each layer adds unnecessary work without real benefit.

If you need to develop upper layers before lower ones, you can simply create empty methods in the lower‑level class.

A recommended top‑down coding process:

Write logic in the Controller first, inserting Service calls as needed.

Complete the Controller flow.

Use the IDE’s auto‑completion to generate the called class and method, adding TODO comments.

After all classes and methods are generated, replace the TODO stubs with real implementations.

This approach helps you understand the business flow early.

Second Reason

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

Third Reason

Having multiple Service implementations is rarely needed; when it is, other techniques can replace interface‑based polymorphism.

Project Structure and Interface Implementation

A typical layered project looks like:

Controller

Service

Dao

If multiple implementations are required, the structure may become:

Controller

Service (interface)

ServiceImpl (implementation 1)

ServiceImpl2 (implementation 2)

Dao

Two approaches to handle multiple implementations:

Add a new package under Service and create a new implementation, adjusting configuration to inject the desired bean.

Create a separate Service module with its own implementation, ensuring package and class names differ to avoid conflicts.

Both approaches introduce extra code; the second gives clearer modular separation.

Combining the Advantages

Separate the interface and its implementations into an independent module:

Controller

Service – interface module

ServiceImpl (implementation)

ServiceImpl2 (alternative implementation)

Dao

By adjusting build dependencies, you can include either ServiceImpl or ServiceImpl2, keeping the package structure identical and avoiding configuration changes.

Drawbacks of Not Using Interfaces

When you need multiple implementations, the lack of a strong interface contract makes IDE assistance and error checking harder. Copying existing code to a new module is an inelegant workaround.

Therefore, if a project requires many implementations, interfaces are recommended; otherwise, they can be omitted.

Conclusion

The article revisits the question “Should Service layers have interfaces?” and presents arguments against mandatory interfaces, while acknowledging scenarios where they are useful.