The SproutCore data store acts as the repository for most of the data that we will load into a SproutCore application. While you can have multiple data stores in your application, you will probably use just one for the sake of simplicity. To create a store, we simply create an instance of SC.Store and in fact, if you use the command line generator (that is, sproutcore gen app), you will find that a store is created for you by default, in the application's core.js file.

We typically create the main application store as a property of the application object. For example:

MyApp = SC.Application.create({
  
  // The main application data store, accessible as 'MyApp.store'
  store: SC.Store.create()
  
});

You can think of the store as an in-memory database. So, if you have a good idea of the type of data that belongs to a database, you will likely have a good idea of the appropriate data for the store by now. For example, if you will be retrieving records of users, accounts, messages, or other similar data types that you would store in a database, these records will be a perfect fit for the data store. On the other hand, the same types of data that you would not store in a database are likewise not a good fit for the data store. For example, if you retrieve a session for the current user, it's not necessary to give this object its own record class and push it in the store.

Much like a database, you will start by loading data into the store and use queries to retrieve specific data back for use in the application as and when necessary. However, because the real root data resides in one or more remote data stores, SproutCore's data store is actually optimized to act as a quick access database cache. For instance, the store always provides records to the application immediately when requested, but if that data doesn't currently exist in the store, the records will initially be empty while the store requests more information through the Data Interface layer. When the real data arrives, it will be loaded into the store and the empty records will be updated. Of course, with the power of bindings and observers, the UI will be updated automatically as well.

One important point to bring up early is that data in the store is stored as a collection of simple JavaScript objects that we call data hashes. Data hashes are just deserialized data from the remote source that are loaded directly into the store. I do realize that this is a lot of jargon and these various terms may not mean much to you yet, but hopefully the following figure will help you visualize the system we have been talking about so far.

On the left are the remote data sources that provide data to our application and on the right is the application's store. As you can see in the figure, our data source adaptors transform the remote serialized data into simple JavaScript objects (that is, data hashes) that the store will manage.

We will look at how to write data source adaptors at the end of this chapter, but for now it's important just to remember that the data hashes will contain only primitive values such as strings, numbers, and booleans. This is because the data transferred between the application and the remote data sources will likely be in a format such as JSON or XML and so, we benefit by keeping our data hashes in an easily serializeable format.

Next, let's look at the components between the store and the rest of the application.