@ngdoc overview
@name Conceptual Overview
@description
There are some concepts within Angular that you should understand before creating your first application.
This section touches all important parts of Angular really quickly using a simple example.
However, it won't explain all details.
For a more in-depth explanation, have a look at the {@link tutorial/ tutorial}.
| Concept          | Description                     |
|------------------|------------------------------------------|
|{@link concepts#template Template}          | HTML with additional markup |
|{@link concepts#directive Directives}        | extend HTML with custom attributes and elements |
|{@link concepts#model Model}             | the data that is shown to the user and with which the user interacts |
|{@link concepts#scope Scope}             | context where the model is stored so that controllers, directives and expressions can access it |
|{@link concepts#expression Expressions}       | access variables and functions from the scope |
|{@link concepts#compiler Compiler}          | parses the template and instantiates directives and expressions |
|{@link concepts#filter Filter}            | formats the value of an expression for display to the user |
|{@link concepts#view View}              | what the user sees (the DOM) |
|{@link concepts#databinding Data Binding}      | sync data between the model and the view |
|{@link concepts#controller Controller}        | the business logic behind views |
|{@link concepts#di Dependency Injection} | Creates and wires objects / functions |
|{@link concepts#injector Injector}          | dependency injection container |
|{@link concepts#module Module}            | configures the Injector |
|{@link concepts#service Service}           | reusable business logic independent of views |
# A first example: Data binding
In the following we will build a form to calculate the costs of an invoice in different currencies.
Let's start with input fields for quantity and cost whose values are multiplied to produce the total of the invoice:
 This looks like normal HTML, with some new markup. In Angular, a file like this is called a
"{@link templates template}". When Angular starts your application, it parses and
processes this new markup from the template using the so called "{@link compiler compiler}".
The loaded, transformed and rendered DOM is then called the "view".
The first kind of new markup are the so called "{@link directive directives}".
They apply special behavior to attributes or elements in the HTML. In the example above we use the
{@link ng.directive:ngApp `ng-app`} attribute, which is linked to a directive that automatically
initializes our application. Angular also defines a directive for the {@link ng.directive:input `input`}
element that adds extra behavior to the element. E.g. it is able to automatically validate that the entered
text is non empty by evaluating the `required` attribute.
The {@link ng.directive:ngModel `ng-model`} directive stores/updates
the value of the input field into/from a variable and shows the validation state of the input field by
adding css classes. In the example we use these css classes to mark an empty input field with a red border.
This looks like normal HTML, with some new markup. In Angular, a file like this is called a
"{@link templates template}". When Angular starts your application, it parses and
processes this new markup from the template using the so called "{@link compiler compiler}".
The loaded, transformed and rendered DOM is then called the "view".
The first kind of new markup are the so called "{@link directive directives}".
They apply special behavior to attributes or elements in the HTML. In the example above we use the
{@link ng.directive:ngApp `ng-app`} attribute, which is linked to a directive that automatically
initializes our application. Angular also defines a directive for the {@link ng.directive:input `input`}
element that adds extra behavior to the element. E.g. it is able to automatically validate that the entered
text is non empty by evaluating the `required` attribute.
The {@link ng.directive:ngModel `ng-model`} directive stores/updates
the value of the input field into/from a variable and shows the validation state of the input field by
adding css classes. In the example we use these css classes to mark an empty input field with a red border.
 # View independent business logic: Services
Right now, the `InvoiceController` contains all logic of our example. When the application grows it
is a good practice to move view independent logic from the controller into a so called
"{@link dev_guide.services service}", so it can be reused by other parts
of the application as well. Later on, we could also change that service to load the exchange rates
from the web, e.g. by calling the Yahoo Finance API, without changing the controller.
Let's refactor our example and move the currency conversion into a service in another file:
# View independent business logic: Services
Right now, the `InvoiceController` contains all logic of our example. When the application grows it
is a good practice to move view independent logic from the controller into a so called
"{@link dev_guide.services service}", so it can be reused by other parts
of the application as well. Later on, we could also change that service to load the exchange rates
from the web, e.g. by calling the Yahoo Finance API, without changing the controller.
Let's refactor our example and move the currency conversion into a service in another file:
 What changed?
We moved the `convertCurrency` function and the definition of the existing currencies
into the new file `finance.js`. But how does the controller
get a hold of the now separated function?
This is where "{@link di Dependency Injection}" comes into play.
Dependency Injection (DI) is a software design pattern that
deals with how objects and functions get created and how they get a hold of their dependencies.
Everything within Angular (directives, filters, controllers,
services, ...) is created and wired using dependency injection. Within Angular,
the DI container is called the "{@link di injector}".
To use DI, there needs to be a place where all the things that should work together are registered.
In Angular, this is the purpose of the so called "{@link module modules}".
When Angular starts, it will use the configuration of the module with the name defined by the `ng-app` directive,
including the configuration of all modules that this module depends on.
In the example above:
The template contains the directive `ng-app="invoice2"`. This tells Angular
to use the `invoice` module as the main module for the application.
The code snippet `angular.module('invoice2', ['finance2'])`  specifies that the `invoice2` module depends on the
`finance2` module. By this, Angular uses the `InvoiceController` as well as the `currencyConverter` service.
Now that Angular knows of all the parts of the application, it needs to create them.
In the previous section we saw that controllers are created using a factory function.
For services there are multiple ways to define their factory
(see the {@link dev_guide.services service guide}).
In the example above, we are using a function that returns the `currencyConverter` function as the factory
for the service.
Back to the initial question: How does the `InvoiceController` get a reference to the `currencyConverter` function?
In Angular, this is done by simply defining arguments on the constructor function. With this, the injector
is able to create the objects in the right order and pass the previously created objects into the
factories of the objects that depend on them.
In our example, the `InvoiceController` has an argument named `currencyConverter`. By this, Angular knows about the
dependency between the controller and the service and calls the controller with the service instance as argument.
The last thing that changed in the example between the previous section and this section is that we
now pass an array to the `module.controller` function, instead of a plain function. The array first
contains the names of the service dependencies that the controller needs. The last entry
in the array is the controller constructor function.
Angular uses this array syntax to define the dependencies so that the DI also works after minifying
the code, which will most probably rename the argument name of the controller constructor function
to something shorter like `a`.
# Accessing the backend
Let's finish our example by fetching the exchange rates from the Yahoo Finance API.
The following example shows how this is done with Angular:
What changed?
We moved the `convertCurrency` function and the definition of the existing currencies
into the new file `finance.js`. But how does the controller
get a hold of the now separated function?
This is where "{@link di Dependency Injection}" comes into play.
Dependency Injection (DI) is a software design pattern that
deals with how objects and functions get created and how they get a hold of their dependencies.
Everything within Angular (directives, filters, controllers,
services, ...) is created and wired using dependency injection. Within Angular,
the DI container is called the "{@link di injector}".
To use DI, there needs to be a place where all the things that should work together are registered.
In Angular, this is the purpose of the so called "{@link module modules}".
When Angular starts, it will use the configuration of the module with the name defined by the `ng-app` directive,
including the configuration of all modules that this module depends on.
In the example above:
The template contains the directive `ng-app="invoice2"`. This tells Angular
to use the `invoice` module as the main module for the application.
The code snippet `angular.module('invoice2', ['finance2'])`  specifies that the `invoice2` module depends on the
`finance2` module. By this, Angular uses the `InvoiceController` as well as the `currencyConverter` service.
Now that Angular knows of all the parts of the application, it needs to create them.
In the previous section we saw that controllers are created using a factory function.
For services there are multiple ways to define their factory
(see the {@link dev_guide.services service guide}).
In the example above, we are using a function that returns the `currencyConverter` function as the factory
for the service.
Back to the initial question: How does the `InvoiceController` get a reference to the `currencyConverter` function?
In Angular, this is done by simply defining arguments on the constructor function. With this, the injector
is able to create the objects in the right order and pass the previously created objects into the
factories of the objects that depend on them.
In our example, the `InvoiceController` has an argument named `currencyConverter`. By this, Angular knows about the
dependency between the controller and the service and calls the controller with the service instance as argument.
The last thing that changed in the example between the previous section and this section is that we
now pass an array to the `module.controller` function, instead of a plain function. The array first
contains the names of the service dependencies that the controller needs. The last entry
in the array is the controller constructor function.
Angular uses this array syntax to define the dependencies so that the DI also works after minifying
the code, which will most probably rename the argument name of the controller constructor function
to something shorter like `a`.
# Accessing the backend
Let's finish our example by fetching the exchange rates from the Yahoo Finance API.
The following example shows how this is done with Angular: