What is the correct way to setup a Model for IOS?

Question

I am creating an app and using Parse.com for Data Storage.

I would like to use a Model for all the different aspects of Parse that I use. For example, if I store some Game data I would like a model to handle doing any finds/updates/entries into a Game model held on Parse.

So I would like a Model to handle all these methods, instead of adding these into the View Controllers.

What is the best/correct way to set these up? I have heard of singletons but not sure if they would be correct here.

At present, I set these up using a subclass of NSObject. I then create all the methods as class methods (no instance methods as there is no instance to create). I then call any class method as usual.

[GameModel classMethodName];

Would this be correct? Is there a better approach or any issues with this approach?

Answer 1

At present, I set these up using a subclass of NSObject. I then create all the methods as class methods (no instance methods as there is no instance to create). I then call any class method as usual.

This doesn't sound like a very good plan. The job of a model is to manage the data that your application operates on. That means that your model should have data to store, which means that you should be instantiating your model.

Building support for your back end infrastructure (Parse, in your case) is a good idea. It's much better to put it there than to put it in your view controllers. But where does that supporting code store the game state, for example, or the player's history? It should store it in the model object(s).

Without getting into the whole singletons good vs. singletons bad can of worms (you should Google that), it sounds like you're using class methods for much the same reason that people often use singletons: easy access. Instantiating your class and using instance methods instead of class methods would mean that you have to find a way to share the model with those objects that need it, and that's more work than just using the globally accessible class methods. Doing that work will make for a better application, though.

For example, you could restrict each view controller's access to just those parts of the model that it needs. The game play view controller might only get to see the current game board, and the high scores view controller would only see the player's history. That eliminates many possible bugs -- you'll never have to wonder if the game board view controller is causing a problem with the player history, because it never sees that part of the model.