Clean Architecture: Understanding the Role of Presenters

Clean Architecture, proposed by Robert C. Martin, is an architectural approach aimed at creating modular, scalable, and maintainable systems. One of its main pillars is the clear separation between layers, where each has well-defined responsibilities. In this article, we will deeply explore the role of Presenters, one of the most important layers in the communication flow between the application layer and the user interface.

What Are Presenters in Clean Architecture?

Presenters are part of the interface layer, whose main responsibility is to prepare data to be displayed to the user in a way the interface can easily consume. They serve as intermediaries between use cases and the user interface, such as a web or mobile application.

In Clean Architecture, Presenters should:

• Transform raw data into View Models: Data coming from use cases is usually not in the ideal format for presentation. The Presenter converts this data into a structure that the interface layer can easily understand.
• Avoid business logic: Any business rules should be handled in the use case layer. The Presenter only manipulates data for display.
• Ensure independence from interface technology: Presenters should not have knowledge of specific details about the technology used in the interface (e.g., React, Angular, or Flutter).

Where Do Presenters Fit in Clean Architecture?

Clean Architecture is composed of four main layers:

1. Entities: Contain the most fundamental business rules and are independent of any other component.
2. Use Cases: Define the specific application rules, using entities to solve business problems.
3. User Interface: Responsible for interaction with the user but dependent on Presenters and View Models to retrieve data.
4. Interface and Infrastructure: Includes details about frameworks, databases, and external APIs.

Presenters act as a bridge between the use case and user interface layers. This separation ensures that changes in the interface or business flow do not directly impact each other.

Practical Example: Implementing a Presenter

Let’s assume we are developing a library system where users can browse a list of available books. The use case returns a list of Book objects with the following properties:

class Book {
    constructor(title, author, publishedDate) {
        this.title = title;
        this.author = author;
        this.publishedDate = publishedDate;
    }
}        

However, the user interface needs to display the books in a more readable format, such as “Book Title (Author) — Published in 10/2023.”

This is where the Presenter comes in, preparing the data. Here’s how it could be implemented in JavaScript:

Presenter

class BookPresenter {
    present(books) {
        return books.map(book => {
            const publishedDate = new Date(book.publishedDate);
            const formattedDate = `${publishedDate.getMonth() + 1}/${publishedDate.getFullYear()}`;
            return `${book.title} (${book.author}) - Published in ${formattedDate}`;
        });
    }
}        

Application Flow

The use case might return data like this:

class GetAvailableBooksUseCase {
    constructor(bookRepository) {
        this.bookRepository = bookRepository;
    }

    execute() {
        return this.bookRepository.findAllAvailableBooks();
    }
}        

And the user interface would receive the formatted data as follows:

class BookController {
    constructor(useCase, presenter) {
        this.useCase = useCase;
        this.presenter = presenter;
    }

    getAvailableBooks() {
        const books = this.useCase.execute();
        return this.presenter.present(books);
    }
}        

Benefits of Using Presenters

1. Separation of Responsibilities: Presenters prevent the interface or use cases from directly manipulating data.
2. Ease of Maintenance: If the display format changes, only the Presenter needs updating.
3. Testability: Presenters are easy to test because their sole responsibility is to format data.
4. Reusability: Presenters can be reused across different parts of the application or even in different interfaces (web, mobile, etc.).

Common Mistakes When Working with Presenters

• Including Business Logic: The Presenter’s responsibility is only to format data. Any other logic should be delegated to the use cases.
• Creating Dependency on User Interface: A Presenter should be independent of the interface technology to ensure it can be easily replaced or modified.
• Underestimating Its Importance: Developers often embed the Presenter’s responsibilities directly into the interface, making the system harder to maintain.

Conclusion

Presenters play a fundamental role in Clean Architecture by ensuring that data is presented in a clear, readable, and decoupled manner from the business logic. While they may seem like a simple abstraction, their proper implementation brings significant gains in maintenance, testability, and code reusability. When designing scalable systems, do not underestimate the power of a well-structured Presenter.

If you are new to Clean Architecture, start by implementing Presenters in small projects and notice how they help organize the code and simplify communication between layers. Happy coding!