When and How Much Data to Load into Model Objects?

I come to iPhone programming from a web development paradigm and am having a bit of a problem understanding how to design my iPhone application.

The crux of my question is: How much data do you load into your model and when do you load it with data from the database?

In the web apps I've created, the objects on the server-side are filled by the database based off form values supplied by each request. Take the example of a simple list. You click a list value, the id for the list is sent to the server (query string), the server loads an object for just that list item, server-side code uses the object, and then destroys it before the page is returned to the user.

With iPhone apps (or I guess any app where objects persist), you could load all the list item objects into a singlet开发者_Go百科on dictionary from the database before the user ever interacts with them. Then you never have to go back to the database when the user clicks on a link. You just load the object from the dictionary.

Alternatively, you could design it like a web app and just go back to the database each time and fill the object with the data requested.

Can you give me any guidance on when to use one way over the other? When do I load the data? I'm tempted to just load a bunch of data when the application starts up so that I never have to go back to the database. But this feels dirty.

• For static data that isn't too large, loading it all at startup works.
• In one of our products, we do this for simplicity on one of the tables (we don't expect more than a few thousand rows) and load the other table lazily (high-res images). This is a reasonable option if you don't have background threads also accessing the database.
• Core Data does batched lazy loading (i.e. it will load a batch of result rows at once).

Sidenote: Writes using Core Data and an SQLite store seem exceptionally slow, to the extent that we moved processing to a background thread to avoid blocking the UI (and this is for not very much data at all) and gained some annoying concurrency issues as a result. Sigh.