patchthecode
commented
8 years ago @onmyway133 Here is a question I asked him on a post here
I’m new to VIPER architecture in swift, so forgive if I misunderstand something ok. In relation to routing/wireframe, On the original VIPER flow, Information went from view/viewController-> Presenter -> wireframe/router. According to the https://www.objc.io/issues/13-architecture/viper/ they have the following quote:
“Since the Presenter contains the logic to react to user inputs, it is the Presenter that knows when to navigate to another screen, and which screen to navigate to. Meanwhile, the wireframe knows how to navigate.”
In CleanSwift however, the view/viewController seems to be the one playing this particular role of the presenter. My question is that since the viewController is now involved in the routing, does that make testing more difficult in anyway? In the original VIPER model, the view/viewController can easily be swapped out while other components are tested. But if in CleanSwift the VC is now involved in routing (and not the Presenter), wouldn’t make the view/VC less of a pluggin when it comes to unit testing?
And here was his response.
You’re right that in VIPER the flow of control is View Controller –> Presenter –> Wireframe. However, the Presenter also talks to the Interactor. Even worse, those arrows are actually bi-directional. The interdependency between the components is kinda messy. It is hard to isolate the components for testing.
You can translate the VIPER quote in Clean Swift terms as follows:
“Since the View Controller contains the logic to react to user inputs, it is the View Controller that knows when to navigate to another screen, and which screen to navigate to. Meanwhile, the router knows how to navigate.”
Imagine you have a button that, when tapped, navigate to a different scene. Who really knows this fact? It’s clearly the view controller because it has the IBAction hooked up to handle that.
The when to navigate is tied to the UI. I don’t think it should be separated out to another component. The how to navigate (i.e. present/popover/dismiss and the transitions) can be extracted to the router.
To force-extract the when to navigate logic to a separate component feels like just moving code around to an unnecessary abstraction layer.
As for testing the view controller’s when to navigate logic, you can simply mock out the router. Then make sure when the button is tapped, mockRouter.navigateToAnotherScene() is invoked.
As for reusability, it is overrated. Realistically, it’s extremely rare that you would want to reuse the view controller, interactor, or presenter. If there is code to be reused, you would put them in workers. The interactors and presenters from multiple scenes can then instantiate the workers to do the common tasks.
I believe application architecture is more important for code organization and ease of making changes, rather than for reusability. You reuse a very specialized part of the code. You don’t reuse architectural components.
Hope that answer your questions about the philosophical differences between VIPER and Clean Swift.
So given those slight differences in architecture, does the VIP implementation breaks the beauty of the VIPER model? I'm not sure that it does. But maybe you could point it out for me? Or maybe you can point me to a swift implementation that allows the use of storyboards, and segues?
Reading http://clean-swift.com/clean-swift-ios-architecture/
I see that VIPER is like putting Presenter in the center of the module. The Presenter conforms to both ViewControllerOuput, InteractorOutput, ... it is like the mediator. Furthermore, it also manages the Router. I find the Presenter a bit ambitious
How did you come up with Clean Swift?