Ember.js is an MVC framework for building applications. MVC is an acronym for "Model, View, Controller," a software architecture pattern used since the earliest graphical user interfaces were created in the 1970s. Fundamentally, it is concerned with drawing clear lines between data, presentation, and interaction.
The definition of MVC components as stated by Trygve Reenskaug, who first documented the pattern:
Models
Models represent knowledge. A model could be a single object (rather uninteresting), or it could be some structure of objects.There should be a one-to-one correspondence between the model and its parts on the one hand, and the represented world as perceived by the owner of the model on the other hand.
Views
A view is a (visual) representation of its model. It would ordinarily highlight certain attributes of the model and suppress others. It is thus acting as a presentation filter.A view is attached to its model (or model part) and gets the data necessary for the presentation from the model by asking questions. It may also update the model by sending appropriate messages. All these questions and messages have to be in the terminology of the model, the view will therefore have to know the semantics of the attributes of the model it represents.
Controllers
A controller is the link between a user and the system. It provides the user with input by arranging for relevant views to present themselves in appropriate places on the screen. It provides means for user output by presenting the user with menus or other means of giving commands and data. The controller receives such user output, translates it into the appropriate messages and pass these messages on to one or more of the views.— Trygve Reenskaug, Models - Views - Controllers, 10 December 1979
The MVC pattern is popular and widely applied, and consequently many flavors and variations exist. Most web developers are familiar with MVC frameworks used for server-side request handling, frameworks like Django or Rails. That variation of MVC has become specialized over the years. In it, models manage persistence, controllers handle HTTP requests, and views present data (often via a template). HTTP is a stateless protocol, and these responsibilities reflect that.
Desktop applications (and smartphone applications) have long used a different variation on the MVC pattern. Where server-side apps are request-driven, desktop applications are interaction driven. Where server-side apps maintain little state from request to request, desktop applications maintain state for as long as the application runs.
The browser environment and concerns of a single-page web app are very similar to those of a desktop application. Consequently, Ember's version of MVC owes much to Cocoa, the OS X and iOS development environment. Models manage persistence, controllers maintain state and decorate models, and views manage the interface layer (in a web application, the DOM).
However, web applications are not desktop applications. One important difference is the presence of URLs. URLs provide a way to share an address, to share the state one user sees with another. URLs are important in Ember, and Ember has a unique and powerful router that drives its MVC parts. Another significant feature of the web is a document-based interface layer, powered by HTML and the DOM. Ember views render templates that allow developers to directly author HTML.
Ember applications are built from several architecture primitives. These next few summaries (and this book in general) try to approach application development from the top down. Instead of focusing on how to manipulate the DOM, we will instead start with how routes and templates are used to compose an application. This holistic approach is how Ember is designed to work best.
The Router and Routes
The router presents developers with a domain specific language for mapping URLs to routes. Ember's router is configurable, and can work with pushState URLs (like /#/cars) or with the HTML5 history API (which uses traditional URLs with no prefix: /cars). The router is responsible for moving the application between routes, which in turn are responsible for tying together models, controllers, and views. Routes do many things asynchronously, and transitions can be cancelled or retried programatically.
Models in Ember
The Ember framework expects models as representations of domain objects. In an application that managed inventory for a furniture store, there would likely be objects for couches, chairs, and tables. All couches would be represented as instances of a Couch class, and could possibly be related to other objects (such as a couch and chair both being members of a living room set).
Ember itself provides no tools for managing relationships between models or persisting data. Other libraries, such as Ember-Data, Ember-Model, or EPF fill this role. Even a library not based on Ember could be used. Some prominent projects, such as Discourse, build their own model layers from scratch.
Ember does not require your models to be complicated (they could be simple objects and arrays), but it does require that you represent your domain objects with them.
Controllers
Ember controllers are responsible for decorating models and managing state. Provided a model, a controller may change how a given property is presented or present new properties. When a template is rendered, the controller (and thus its decorations) are provided as the context. Additionally, a controller will manage the state of an application. For example, the currentUser of a given session would be maintained on a controller.
Controllers come in a singleton or transient flavor. Most controllers in Ember are singletons. When a property is set (such as the currentUser), it will remain set regardless of whether that controller is backing a visible template. There are other occasions where controllers are only intended to decorate, or maintain temporary states, and in those situations the controller may eventually be destroyed. These can be called transient controllers.
Templates and Views (and Components)
Ember uses Handlebars templates with data-binding for interface creation. When a variable is displayed by Handlebars, the DOM will be automatically updated to reflect changes in that property's value. By convention, a route will render a template with a controller as context. In this way, a template often displays a decorated model.
Views in Ember are responsible for managing the process of rendering a template, and for handling DOM events like clicks or mouse movement. If an application uses a jQuery plugin to change the DOM, a view is where the plugin would be used. Views in Ember are often implied, since templates and controllers are very powerful.
Ember also provides for components. These are reusable pieces of logic for use in templates, and comparisons are often made between components and custom HTML tags. Components are supposed to be self-contained, so not only do the have the responsibilities of a view, but they also present data as a controller would.
There is another way of thinking about the MVC pattern in relation to Ember, and that is in terms of application state. It goes something like this:
This notion can be useful when deciding where to store a particular piece of data. For example, imagine a music streaming app: The open/closed state of a "more info" tab for a specific album could be on an item controller (which is transient), while the currently playing song could be on a controller (open for the duration of a user's session), and the playlist present as a model (persisted to a storage endpoint).
Hopefully this quick primer has given a basic idea of where Ember gets its design from, and the solidity these foundations provide.
Now that we’ve introduced this overall design pattern, it’s time to dive into the individual components that make all this work. In the next chapter, we’ll explore the object-oriented programming features Ember adds to JavaScript.
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.