|
1 | | -# SimpleVIPExample |
2 | | - |
| 1 | +# Clean VIP |
| 2 | + |
| 3 | +An Example of Clean VIP Architecture. |
| 4 | + |
| 5 | +We will discuss Uncle Bob’s Clean architecture here followed by a sample project. As we have seen, MVC architecture turned into massive view controllers with respect to time to a time change requests that lead us to difficulties from a testing perspective for each module. |
| 6 | + |
| 7 | +Below are the components of this Architecture : |
| 8 | + |
| 9 | +* View Controller |
| 10 | +* Interactor |
| 11 | +* Presenter |
| 12 | +* Router |
| 13 | +* Models |
| 14 | + |
| 15 | +### Protocols are used here throughout the components to pass data and vice versa. |
| 16 | +Protocols are used widely throughout the components to pass & receive data/messages. |
| 17 | + |
| 18 | +## View Controller |
| 19 | + |
| 20 | +* Defines a scene and contains a view or views. |
| 21 | + |
| 22 | +* Keeps instances of the interactor and router. |
| 23 | + |
| 24 | +* Passes the actions from views to the interactor (output) and takes the presenter actions as input |
| 25 | + |
| 26 | +## Interactor |
| 27 | + |
| 28 | +* Contains a Scene’s business logic. |
| 29 | + |
| 30 | +* Keeps a reference to the presenter. |
| 31 | + |
| 32 | +* Runs actions on workers based on input (from the View Controller), triggers and passes the output to the presenter. |
| 33 | + |
| 34 | +* The interactor should never import the UIKit. |
| 35 | + |
| 36 | +## Presenter |
| 37 | + |
| 38 | +* Keeps a weak reference to the view controller that is an output of the presenter. |
| 39 | + |
| 40 | +* After the interactor produces some results, it passes the response to the presenter. Next, the presenter marshals the response into view models suitable for display and then passes the view models back to the view controller for display to the user. |
| 41 | + |
| 42 | +## Router |
| 43 | + |
| 44 | +* Extracts this navigation logic out of the view controller. |
| 45 | + |
| 46 | +* Keeps a weak reference to the source (View Controller). |
| 47 | + |
| 48 | +## Configurator |
| 49 | + |
| 50 | +* Takes the responsibility of configuring the VIP cycle by encapsulating the creation of all instances and assigning them where needed. |
| 51 | + |
| 52 | +## Model |
| 53 | + |
| 54 | +* Decoupled data abstractions. |
| 55 | + |
| 56 | +## When and why We should use it |
| 57 | + |
| 58 | +* Projects where unit testing is expected. |
| 59 | + |
| 60 | +* Long-term and big projects. |
| 61 | + |
| 62 | +* Projects with a generous amount of logic. |
| 63 | + |
| 64 | +* Projects you want to reuse in the future. |
| 65 | + |
| 66 | +## Strengths |
| 67 | + |
| 68 | +* Easy to maintain and fix bugs. |
| 69 | + |
| 70 | +* Enforces modularity to write shorter methods with a single responsibility. |
| 71 | + |
| 72 | +* Nice for decoupling class dependencies with established boundaries. |
| 73 | + |
| 74 | +* Extracts business logic from view controllers into interactors. |
| 75 | + |
| 76 | +* Applies to existing projects of any size. |
| 77 | + |
| 78 | +* Modular: Interfaces may be easy to change without changing the rest of the system due to using protocol conformant business logic |
| 79 | + |
| 80 | +## Disadvantages |
| 81 | + |
| 82 | +* Many protocols with complicated naming and responsibilities |
| 83 | + |
| 84 | +* Large app size due to many protocols. |
| 85 | + |
| 86 | +* Despite the fact that there is an official website of Clean Swift architecture, it changes often and implementations may differ between projects. (https://clean-swift.com/clean-swift-ios-architecture/) |
| 87 | + |
| 88 | + |
| 89 | +## Official implementation guide |
| 90 | + |
| 91 | +https://clean-swift.com/clean-swift-ios-architecture/ |
| 92 | + |
| 93 | + |
0 commit comments