MVC Model Implementation?

I am creating a simple application using the MVC design pattern where my model accesses data off the web and makes it available to my controllers for subsequent display.

After a little research I have decided that one method would be to implement my model as a singleton so that I can access it as a shared instance from any of my controllers.

Having said that the more I read about singletons the more I notice people saying there are few situations where a better solution is not possible.

If I don't use a singleton I am confused as to where I might create my model class. I am not over happy about doing it via the appDelegate and it does not seem viable to put it in any of the viewControllers.

any comments or pointers would be much appreciated.

EDIT_001:

TechZen, very much appreciated (fantastic answer as always) can I add one further bit to the question before making it accepted. What are your thoughts on deallocating the singleton when the app exits? I am not sure how important this is as I know quite often that object deallocs are not called on app teardown as they will be cleared when the app exits anyway. Apparently I could register the 开发者_如何学Goshared instance with NSApplicationWillTerminateNotification, is that worth doing, just curious?

gary

There is a lot of push back on the use of singletons because they are often abused. Lazy coders either (1) don't put enough functionality in the singleton which results in having logic spread out in other objects like spaghetti or (2) they put in to much functionality such that the singleton becomes the entire program. Lazy coders way to often use singletons instead of doing data validation, object testing and object tracking. People get sick of trying to untangle and maintain lazy singleton use so they try to suppress the use of singletons.

I thoroughly understand the impulse and I myself ritualistically warn against singleton abuse.

However, a data model is one of the few legitimate uses for a singleton. This is especially true in small apps like those which run on mobiles. In the end, you will either use a singleton for your data model or you will attach it to a singleton.

For example, suppose you decide to park your non-singleton data model object in the app delegate. Well, you've done this: dataModel-->appDelegate-->application(singleton). To access it, you would call:

 [[[UIApplication sharedApplication (a singleton)] delegate] theDataModelObj];

Even if you pass it around like a token from object to object you will still have to have the dataModel obj begin as the property of a singleton.

When an object really does have to meet the "Highlander" pattern ("There can be only one!") then a singleton is the best choice. In addition to the application object, you have user defaults as a singleton as well as the file manager. Clearly, in all three cases, you want one and only one instance in existence for the entire app. For example, if you had more than one user defaults object, your app would be a train wreck trying to track all the preference settings. If you have more than one file manager, file operations could step on one another.

A properly designed user data model is just a larger version of user defaults. It should be the only object that directly manipulates the user's data. No other object in the app should have that task in the least. That makes the singleton design pattern the best one to use in this particular case.

Singletons are a very powerful tool but just as with a physical tools, the more power they give you, the more opportunities they create for you to cut you head off if you use them carelessly. For this reason, a singleton should seldom be your first choice. There are usually better design patterns to employ.

However, when you really need a singleton, you shouldn't shy away from using them just because the laziness of others has given them a bad rep.

Knowing when and when not to use a powerful and dangerous tool is part of the programmers intuition you develop with experience. You can't go by formula. It is one of those factors that makes good coding an art and the programmer a craftsman.