1

I've been working on a personal project so to better understand the VIPER architecture. I really like the way I can keep modules separated, making the code cleaner.

I still have some doubts when it comes to modules dependencies:

I have one module responsible to show some statistics based on user's data and another module responsible to show some data projections based on statistics.

My ProjectionsInteractor then, needs to take some data from the StatisticsInteractor, as I don't want to reimplement the same stuff twice.

I already have a DataManager layer, that is basically a CoreDataManager, but there isn't any logic there. It's just used by the Interactors to retrieve and manipulate some data without knowing anything about the Persistence details.

Where do I put commonality factored out from multiple interactors? Does it make a difference:

  • whether the commonality is related to the core {data-store, networking, sensors} data-acquisition/storage purpose of interactors versus
  • whether the commonality is related to business rules to be enforced on that data acquired from {data-store, networking, sensors}?
Andreas ZUERCHER
  • 862
  • 1
  • 7
  • 20
Luigi Trevisi
  • 81
  • 1
  • 7
  • i could not understand your confusion. Are confused about using one interactor in two modules ?? – Md. Sulayman Jul 12 '18 at 09:53
  • 1
    My question is: is it ok to call some Interactors' methods from another Interactor? Because I feel like this violates the modules indipendency – Luigi Trevisi Jul 12 '18 at 10:00
  • I think so. I would create a different class to fetch or process your data which you use as statistics and use that class to provide data on that two different Interactor. I won't create one interactor for two module – Md. Sulayman Jul 12 '18 at 10:03
  • Would it mean move the entire business logic in this new class (an helper?) and basically making the Statistics Interactor a simple dispatcher? – Luigi Trevisi Jul 12 '18 at 10:08
  • Yes. I would have implement that on this way. As , it don't violate any of the VIPER's policy – Md. Sulayman Jul 12 '18 at 10:11
  • Ok thank you for the suggestion! – Luigi Trevisi Jul 12 '18 at 10:16

1 Answers1

0
  • If the commonality is app-domain business-rule in nature, factor out the commonality to move it to presenter zone, which is where all app-domain business rules are to be housed in VIPER architecture.
  • But if the commonality is interactor-centric in nature, instead of having one interactor invoke another interactor's methods, you would factor out the commonality among interactors into a library within interactor zone that multiple interactors would invoke. That library could take several forms: either a utility layer (as from a more traditional era) or a protocol for the interactors that need the commonality to inherit from.

TL;DR: Factor out the commonality. Where to put the factored-out commonality depends on what topic/characteristics the commonality is.

Andreas ZUERCHER
  • 862
  • 1
  • 7
  • 20