3

In an iOS VIPER project, there is a need to call a remote service (e.g. refresh token + check user login ) in every module. What is the best practice of implementing this need?

  • Can we have multiple interactors per module?

  • Or Should we implement the same business logic in every module (interactor)?

  • Should we separate interactors from modules (like network) and share between modules as they needed?

In most samples I studied, they usually talk about different business logic, not the same ones!

Andreas ZUERCHER
  • 862
  • 1
  • 7
  • 20
riza milani
  • 163
  • 1
  • 7

2 Answers2

1

Everyone has his own viper!! This is a common architecture. Each team uses different approaches to its use. And even for one team, they can vary depending on the project. I think you need to find a compromise between convenience and architecture. Each developer and for each project has its own best practice in building dependencies. p.s. in accordance with the architecture, all communication with the network / disk comes from the interactor. it can be organized in different ways and this has nothing to do with VIPER. The creation of a network service or the reuse of interactor etc. depends on your ..... desires)

flowGlen
  • 627
  • 3
  • 11
  • Precise answer!!! As per your need you can make it module and write it on one layer. Considering your case, creating a **network layer** and using it from **interactors** all over would be a good approach. – Vijay Sanghavi Apr 30 '19 at 06:20
  • Thanks, but I'm looking for more specific answer. I want to use correct isolation and seperation in architecture. – riza milani Apr 30 '19 at 09:43
  • Define “everyone”. If everyone means each developer, uh, no! If everyone means each team, perhaps. If everyone has his own VIPER module means beauty is in the eye of the beholder, so do what feels correct, then yes. – Andreas ZUERCHER Apr 02 '21 at 03:44
  • The question was about the organization of interactors, their re-use and their dependence on services and managers. This organization depends on the project -> project is a team -> the team consists of developers! So it turns out - everyone has their own VIPER)) – flowGlen Apr 02 '21 at 06:53
1

There should be one VIPER module per cohesive portion of the app that makes sense to have strong internal cohesion with relatively little adhesion between VIPER modules (e.g., service interfaces to each other). Telecom software architecture has for decades had such separate modules/subsystems that would each be its own VIPER module (if not broken down a internally into just a few VIPER modules, but let's skip that); it is called FCAPS: https://en.wikipedia.org/wiki/FCAPS which shows the drastically different purposes of a large software system broken down into distinct modules of:

  • Fault isolation via dependency directed acyclic graph to drive inferences of which anomalous symptoms indicate what is wrong
  • Configuration-settings of how the system is configured properly (rejecting prohibited configuration-settings) by it various tunable parameters
  • Accounting-billing of how the operation of the system commences, assures continuity of, and retires billable events for revenue generation
  • Performance of how the operation of the system can forecast trends approaching systemic duress or individual component failure (e.g., a member of a pool of resources)
  • Security of how unauthorized or unauthenticated or unfunded usage of the system is prohibited

This isn't the only conceivable way of demarcating the most-macroscopic VIPER modules, but it is a well-thought-out demarcation of modules/subsystems that eventually nearly every large software system/app needs that is orthogonal as management duties to whatever the main purpose of the system/app is, which of course would be its own 1 or more VIPER modules, one for each major broad technical achievement topic of the system/app—whatever the most-macroscopic collection of use-cases are (e.g., creation of new stuff as 1 VIPER module, retention of a retrievable archive of a history of old stuff as another VIPER module, deleting cruft out of the archive as another VIPER module, and so forth, of which each of these might have quite a few use-cases under those broad umbrellas).

Andreas ZUERCHER
  • 862
  • 1
  • 7
  • 20