Before we closely look at the View layer, we should take a moment to understand SproutCore's MVC architecture. I use the term MVC here more often for the pattern's familiarity to most developers than for any other hard and fast interpretation because, the important part of the theory isn't the names or arrangements of the layers as much as it is the idea of separation of concerns.

Therefore, I'd rather not spend much time trying to theorize the differences between client-side and server-side MVC, or between MVC and Model-View-View-Model (MVVM), or some other arrangement. Instead, we'll focus only on the role of each MVC layer in SproutCore and how they help us with our main concern, which is writing excellent softwares.

Since SproutCore runs entirely within the client, it does change the dynamics of many things, including the role of the MVC layers. For a quick reference, SproutCore's MVC arrangement closely resembles MVC in the Cocoa framework, but since MVC in any form does not define the entire architecture required for a client-side web application, we will introduce three additional layers: the Display layer, the Application State layer, and the Data Interface layer.

The following is a figure of all the layers in a SproutCore application which shows MVC and these additional layers:

The first new layer is the Display layer, which is essentially the web browser in this case. Unlike a native application, a web application's views cannot paint directly to the screen. Instead, the views' role is to generate the HTML that will be passed to the browser so that the browser can determine what to draw on the screen. This is the case for all web applications and I've drawn it outside the SproutCore Application box because we don't provide this layer ourselves; it is provided by the browser and we simply use it.

The second new layer is actually not specific to web applications and certainly not common to all frameworks, although it should be! I've named this layer Application State, which as the name implies, is the layer responsible for maintaining the state of the application. Every application has an inherent application state, usually mixed somewhere inside the other MVC layers, but in SproutCore we formalize this in its own important layer. We will look at the Application State layer in detail alongside the Controller layer in Chapter 5, The Controller Layer.

The final new layer is the Data Interface layer. This layer is responsible for providing data to the Model layer by interfacing with one or more remote data stores. The remote data store may be a server on the Internet or a local IndexedDB database in the client, but regardless of what it is, the Data Interface layer is the one that provides read and write access to it. We will look at the Data Interface layer further alongside the model layer in the next chapter.

Finally, as you must have noticed from the preceding figure, the View layer is stacked upon the Controller layer, which is stacked upon the Model layer. In SproutCore MVC, views do not interact with models directly. Instead, views and models are bound to controllers, which allow the controllers to proxy and transform the data as necessary. We will have a more detailed look on this in Chapter 5, The Controller Layer.