VIPER - Should the Interactor return only the necessary information?

Question

In the VIPER design pattern, should the Interactor return all the information that might be used by multiple presenter actions or should I have a separate struct for each one?

In my case, I have a map that displays places. To display those places I need to retrieve a list of PlaceItem's from a PlacesInteractor which could have only a coordinate and a color (used to change the pin's head color) that would be transformed into a annotations by the presenter.

Now lets say that when the user selects one of the annotations in the map, a callout bubble should be displayed with more details like the place's name and a circle with the color.

Now I should create a RetrievePlaceCalloutInteractor that would return only the information for one place instead of a list of information for multiple places (Right? Or should I have only one Interactor for both scenarios?).

Should this RetrievePlaceCalloutInteractor return a PlaceCalloutItem with only the name and the color (no coordinate) of the place or should I have a single PlaceItem with coordinate, color and name, that would be returned by the RetrievePlaceCalloutInteractor and by the PlaceInteractor, and would be used by the presenter to construct either a CalloutStruct or a list of MKAnnotations?

Thank you.

Manor

Hi Rodrigo, just a quick comment. It sounds like you should simply include the name in the PlaceItem object in this particular scenario. In my examination of VIPER I generally have one Interactor per screen that has methods for all of the information the view may require. That is unless it is a common set of business logic that is required by a number of screens, then I either have two (or more) interactors referenced in the view or let the specific view interactor determine which other interactors to go to for information. I still have not determined which is the best approach yet for that. – Airing

Answer 1

VIPER is a pattern, not a very formal pattern, not a religion or a complete app architecture. For me VIPER helped to think more about a cleaner architecture but on the way I had to make decisions that were better for my specific scenario without caring to much about VIPER but about clean architecture. So, from my experience and my point of view the answer to your question is 'depends'.

In my case most of the 'Items' (I call them DO from Display Object or Data Object) have almost a one to one relationship with the 'Entities' (I call them MO from Model Object). Most of the interactors manipulate one type of Entity and they have one MO-DO mapper. I usually use the same DO for different use cases if the interactor handle more than one use case.

BUT

I also have some modules using different DOs for different uses cases, although they relate to the same entity, and also I have some DOs with combine the information of several Entities, let's say for example I needed the user name to add it to 'edited by' of a blog post I use the same DO to combine Post and User Entities.

I think VIPER 'wants' one interactor per module, that kind of forces you to have multiple use cases (related) in it, but it is up to you if you want to use different Items (my DOs) or only one.

Being a purist of clean architecture you should have different interactors, different requests and different responses for each use case.

So, as I started, it depends, the important thing is to 'draw' the boundaries properly and it doesn't matter if it's one or ten Items you use for that.

Journalize