Let’s Learn Ember : Ember Architecture

From this post onwards, I will continue my “Let’s Learn Ember” series by delving into the application components that make up the Ember.js archnitecture. You can refresh your Ember.js basics in my last posts that dealt with installation stuffs and the object model of Ember.

Let’s get started with the very basics of Ember architecture. It is very important to know how components are coupled together in Ember because Ember has a very unique way of doing things. Even a little mistake here or there may cause hours of headaches! 🙂

But before we dive into Ember.js architecture, it would be a good idea to understand how applications are developed generally.

Server-side MVC

Most of the web applications are built using MVC pattern. The following snapshot outlines the standard workflow of a server-side MVC application. This is the procedural way of delivering the content from the server to the browser.

ServersideMVC

  • A request from the browser or any Httpclient is sent to the server.
  • The server contains the application and processes data returned from the request.
  • The router first process the request url and dispatches the correct behaviour. It is responsible for filtering out which behaviour the browser wants. It dispatches correct controller that renders a particular view or template that is delivered to the browser. The view can an html, javacript or json.
  • The data is handled by Models and the controllers have direct access to the models.
  •  Once the router knows which controller should take action, it delegates the responsibility to the controller. So the controller handles everything from that moment on.
  • The data is retrieved by the controller via different models. It then dispatches a new view that is to be delivered to the browser.

Client-side MVC

The architecture of Ember, however, does not work the same way. The entire application is centered in the browser in Ember. All of the controllers, views, models, routers are stored in the application in javascript.

ClientsideMVC

  • First of all, the router processes the each request url correctly and maps it to the appropriate controller.
  • The controller then renders a view , which in turn renders a template.
  • So far, the architecture may resemble the server side architecture. But the difference lies on how the models are dealt with in client-side architecture. Since, Ember.js follows clients-side MVC  pattern, it might not be feasible to store the data on the browser or any other client end-points.
  • Hence, Ember.js introduces the concept of “Store”. It is an object that handles the responsibility of retrieving and saving data in form of models.
  • Router has the responsibility of retrieving the content from the store which in turn retrieves the models and respective data to the controller.
  • So controllers simply manipulates what’s in the application in client-side and not in the server-side.
  • Each component share a partial responsibility towards one another. The controller manages views and interacts with the router. The store manipulates the models. All the data comes through the store. Router is responsible for accessing those models into the controller.
  • So, the model data passes through the router which delegates the information into the controller, in form of a proxy.
  • If the view wants to access the models in order to represent its data, it needs to ask the controller which in turns proxies the request to the model.
  • The main catch here is that there are multiple controllers in memory in client-side architecture. There will one controller for list of items, another for a single item and so forth. Each controller has a single responsibility.

Naming Conventions

To understand the naming conventions implemented by Ember, let’s take an example of a standard request for a list of bookmark items. When the browsers makes a request for a list of bookmarks items, there should be corresponding route, controller, view and model. If anyone of them is not present, then Ember creates them for us via active code generation pattern. It is of utmost importance that one grasp the standard naming convention of Ember, as it will ease the learning process.

Naming_Convention

In my post, I have tried to explain the Ember architecture, while contrasting the server-side architecture with client-side architecture.In the coming posts, we will look into each application component in detail, starting with Router.

Till then, Happy coding!! 🙂

Let’s Learn Ember – Observers

After a one-month break, I am finally continuing my “Let’s Learn Ember” series. In this post, I will delve into the in-and-outs of Observers. Let’s get started!

WHAT ARE OBSERVERS?

Observers are those objects that “observe” any property including computed properties in Ember. We can achieve this by setting up an observer on an object using the “observes” method on a function.

AN EXAMPLE

Let’s start with a computed property “fullName” defined as below. It depends upon the properties “firstName” and “lastName”. This means that whenever any one of the property changes, the value of the computed property is updated.

observer1

Continue reading