I am creating a login app for iOS and have stumbled upon a design issue. In my app some data (e.g. current user id
) has to be shared across view controllers so my initial thought was to hold that data in the AppDelegate
and just call it from there whenever it was needed. This would work but it would mean that the AppDelegate
would be doing work that it wasn't intended to do and hence it would be bad architecture, so I thought of creating a singleton class to hold all the shared data instead. This seems to be more focused and I have used this strategy in some of my previous apps, but googling the best practices for singleton classes, I found many results against using them, as they:
- Hide dependencies
- Violate the single responsibility principle
- Make unit testing difficult
(taken from the top answer to this question: What is so bad about singletons?)
The alternative to the two other design patterns would then be to pass data back an forth between view controllers, but this again seems inappropriate. Take for example the current user id
I would have to pass it from the login view controller to the main view controller (which is the same for all users), then from the main view controller to a more specified view controller which is customized for the user. In this case the main view controller is holding data only for the purpose of passing it to the more specific view controller and to me this also seems to violate the single responsibility principle. Would it be bad design to let the main view controller hold data it doesn't need or is there a better alternative?
Aucun commentaire:
Enregistrer un commentaire