Clean-Swift / CleanStore

A sample iOS app built using the Clean Swift architecture. Clean Swift is Uncle Bob's Clean Architecture applied to iOS and Mac projects. CleanStore demonstrates Clean Swift by implementing the create order use case described by in Uncle Bob's talks.
https://clean-swift.com/clean-swift-ios-architecture/
MIT License
1.91k stars 315 forks source link

Where to config? #5

Open onmyway133 opened 8 years ago

onmyway133 commented 8 years ago

In https://github.com/Clean-Swift/CleanStore/blob/master/CleanStore/Scenes/CreateOrder/CreateOrderViewController.swift,

override func awakeFromNib()
  {
    super.awakeFromNib()
    CreateOrderConfigurator.sharedInstance.configure(self)
  }

We lean on the life cycle of the ViewController to config things. How about moving Configuration task to where the module is created?

ehlersd commented 8 years ago

?? Are you suggesting calling the configure in the parent where the module is allocated?

onmyway133 commented 8 years ago

@ehlersd yes, it is. Like Wireframe in VIPER, it initiates and configs the next whole module

ehlersd commented 8 years ago

Hmmm....I haven't dug into VIPER before. Personally, I can see arguments for both ways.

Pro CleanSwift Configurator: Having the config code inside the scene removes any outside responsibility for the scene as a whole, and keeps redundant initialization code inside the scene itself. This makes it easy to copy the scene (as a whole) to another project and "hook it up" thru the storyboard with literally zero code change/additions to the existing app base.

Pro VIPER Wireframe: If you move beyond treating the scene as a whole unit, and instead look at the different pieces as "reusable" and interchangable, then it does make sense to pull the config code out of the scene itself, as the outside source (ie: Wireframe) can pick and choose what Presenter and what Interactor is hooked up to what View (ie: DI). IMHO, there is a lot of value in this approach, IF you are looking for that level of decoupling.

I've approached my scenes slightly different. I've pulled out most of the "reusability" into separate "Workers" (which also are connected using defined protocols), so the reusability of the Interactor and Presenter are limited. The Interactor is much more of JUST business logic, specially designed for this specific view. Also, I tread the scenes as individual "lego" parts that cannot be separated.

But, of course, I see the value in both approaches. I may have to play with VIPER some on a future project.