So Clean Architecture for iOS

Over the years, the phần mềm di động industry has grown at a breakneck pace. In the past, mobile applications were mostly small and often contained few screens. While now there are many giant applications, with very complex user interface and business logic .

For complex applications, the traditional MVC model reveals many shortcomings such as: View and Controller are so closely related that the Model part is almost isolated which makes testing very difficult, ViewController Bigger because both the bussiness logic and the view logic make it difficult to read and understand the code for maintenance and expansion … Clean Architecture was born to solve the above problems by clearly separating modules based on separate tasks.

Clean Architecture

Clean Architecture was introduced by Robert C. Martin (aka Uncle Bob) and received great attention from developers. Clean Architecture is a business architecture that separates business processes from the UI and framework, defining the roles and responsibilities of each layer in its architecture.

The Anatomy of the Clean Architecture

There are many variations of Clean Architecture , in iOS you can hear about VIPER or CleanSwift . When jumping to other platforms like .NET or Android even more variants. However, all variants have the same task of separating business processes from the UI and the framework and following the rules of the Clean Architecture .

Here is a list of components in the architecture:

• View : The interface shows where the interaction between the app and the user occurs, such as Storyboard or XIB.
• Controller : Get actions or events from the view and update it.
• Interactor : The business logic class where the Controller sends requests.
• Presenter : Get feedback from Interactor to send back to Controller.
• Router : The task of navigating the ViewController.

The core of the architecture is the Controller , Interactor , and Presenter . An important thing to note is that the unidirectional Data Flow architecture means that data will move in a specific flow, which greatly reduces the complexity and ease of management.

How it works:

1. Users interact with the View
2. Controller receives event from View to send to Interactor .
3. Interactor implements business logic and returns result to Presenter
4. Presenter reformats the data and then sends it back to the Controller via viewModel
5. The controller receives data from the Presenter then updates the view.

Practice

We define the use-case for each respective layer

This is the flow that occurs at viewDidload interactor.fetchProducts > presenter.presentFetchedProducts > controller.displayFetchedProducts.

Controller :

The controller creates a router and an instance to Interactor through a presenter. Call Interactor in viewDidload to fetch list product.

Inject 1 productsWorker at Interactor to handle API.

Presenter will format the respone data and call the controller to display it on the View

Model are encapsulated in an enum and relate only to its own use case.

Finally, the Router is responsible for controlling the flow of the application: