angular-cn/public/docs/ts/latest/guide/architecture.jade

include ../_util-fns

:marked
  Angular 2 is a framework to help us build client applications in HTML and JavaScript.
  
  Angular 2是一个使用HTML和JavaScript构建客户端应用的框架。
  
  The framework consists of several cooperating libraries, some of them core and some optional.
  
  这个框架包括一系列紧密合作的库，有些是核心库，有些是可选库。
  
  We write applications by composing HTML *templates* with Angularized-markup, 
  writing *component* classes to manage those templates, adding application logic in *services*,
  and handing the top root component to Angular's *bootstrapper*. 
  
  我们用带有Angular标记的HTML写 *模板* ，用 *组件* 类来管理这些模板，用 *服务* 添加应用逻辑，用根组件来完成Angular *启动* 。
  把这些组合起来，我们就得到了一个应用程序。
  
  Angular takes over, presenting our application content in a browser and responding to user interactions
  according to the instructions we provided.
  
  Angular在浏览器中接管、展现我们的应用内容，并且根据我们提供的指令响应用户的交互。
  
<!-- figure img(src="/resources/images/devguide/architecture/airplane.png" alt="Us" align="left" style="width:200px; margin-left:-40px;margin-right:10px" ) -->
:marked
  Of course there is more to it than this. We'll learn the details when we dive into the guide chapters.
  Let's get the big picture first.

  当然，这只是冰山一角。随着内容的深入，我们还会学到更多的细节。
  我们先来看看宏观图景。

figure
  img(src="/resources/images/devguide/architecture/overview2.png" alt="overview" style="margin-left:-40px;" width="700")
:marked
  The architecture diagram identifies the eight main building blocks of an Angular 2 application:
  
  这个架构图展现了Angular应用中的8个主要构造块：
  1. [Module](#module)   
  1. [模块(Module)](#module)
  1. [Component](#component)
  1. [组件(Component)](#component)
  1. [Template](#template)
  1. [模板(Template)](#template)
  1. [Metadata](#metadata)
  1. [元数据(Metadata)](#metadata)
  1. [Data Binding](#data-binding)
  1. [数据绑定(Data Binding)](#data-binding)
  1. [Service](#service)
  1. [服务(Service)](#service)
  1. [Directive](#directive)
  1. [指令(Directive)](#directive)
  1. [Dependency Injection](#dependency-injection)
  1. [依赖注入(Dependency Injection)](#dependency-injection)

  Learn these eight and we're on our way.
  
  我们这一路上就将学习这8点。

.l-sub-section
  :marked
      The code referenced in this chapter is available as a [live example](/resources/live-examples/architecture/ts/plnkr.html).
      
      本章所引用的代码可以在这个[鲜活范例](/resources/live-examples/architecture/ts/plnkr.html)中找到。
<a id="module"></a>
.l-main-section
:marked
  ## The Module
  ## 模块
figure
  img(src="/resources/images/devguide/architecture/module.png" alt="模块" align="left" style="width:240px; margin-left:-40px;margin-right:10px" )
:marked
  Angular apps are modular. 
  
  Angular应用是模块化的。
  
  In general we assemble our application from many **modules**.
  
  我们的程序通常都是由很多 *模块* 组装成的。
  
  A typical module is a cohesive block of code dedicated to a single purpose.
  A module **exports** something of value in that code, typically one thing such as a class.
  
  典型的组件是一个内聚的代码块组成的，用以完成单一的目的。
  <br clear="all"><br>
.l-sub-section
  :marked
     ### Modules are optional
     ### 组件是可选的
     We highly recommend modular design. TypeScript has great support for ES2015 module syntax and our chapters assume we're taking a modular
     approach using that syntax. That's why we list *Module* among the basic building blocks.
     
     我们强烈推荐遵循模块化设计。TypeScript对ES2015的模块语法支持很好，本章假定我们使用那些语法作为模块化方案。这就是为什么我们要把 *模块* 列为一种基本构造块。
     
     Angular itself doesn't require a modular approach nor this particular syntax. Don't use it if you don't want it.
     Each chapter has plenty to offer after you steer clear of the `import` and `export` statements.
     
     Angular本身并不需要模块化方案或使用这种特定的语法。如果你不喜欢，可以不用它。
     在你弄清楚了`import`和`export`语句之后，它在每章都会出现很多。
     
     Find setup and organization clues in the JavaScript track (select it from the combo-box at the top of this page) 
     which demonstrates Angular 2 development with plain old JavaScript and no module system. 
     
     在JavaScript（可以从页面顶部的组合框选择它）分支下，可以找到如何安装和进行文件组织的线索。
     它示范了如何用老版本的JavaScript语言，在没有模块化系统的情况下进行Angular 2开发。
:marked
  Perhaps the first module we meet is a module that exports a *component* class. 
  The component is one of the basic Angular blocks, we write a lot of them,
  and we'll talk about components in the next segment. For the moment it is enough to know that a
  component class is the kind of thing we'd export from a module.
  
  也许我们遇到的第一个模块，就是用于导出 *组件* 类的那个。
  组件是Angular最基本的构造块之一，我们会写很多。下一段，我们将会讨论组件。
  但目前，只要知道组件类需要我们从模块中导出就行了。
  
  Most applications have an `AppComponent`. By convention, we'll find it in a file named `app.component.ts`. 
  Look inside such a file and we'll see an `export` statement like this one.
  
  大多数应用都有一个`AppComponent`。作为一项惯例，它会位于一个名叫`app.component.ts`的文件中。
  打开它，我们将会看到一个`export`语句，就像这样：
+makeExample('architecture/ts/app/app.component.ts', 'export', 'app/app.component.ts (节选)')(format=".")
:marked
  The `export` statement tells TypeScript that this is a module whose
  `AppComponent` class is public and accessible to other modules of the application.
  
  `export`语句告诉TypeScript：这是一个模块，`AppComponent`类是公开的，可以被应用中的其它模块访问。
  
  When we need a reference to the `AppComponent`, we **import** it like this:
  
  当我们需要引用`AppComponent`时，我们 **导入** 它，就像这样：
+makeExample('architecture/ts/app/main.ts', 'import', 'app/main.ts (节选)')(format=".")
:marked
  The `import` statement tells the system it can get an `AppComponent` from a module named `app.component`
  located in a neighboring file. 
  The **module name** (AKA module id) is often the same as the filename without its extension.
  
  `import`语句告诉系统，它能从附近一个叫作`app.component`的文件中获得一个`AppComponent`组件。
  **模块名** （又叫模块ID）通常和去掉扩展名后的文件名相同。
  ### Library Modules 
  ### 库模块
figure
  img(src="/resources/images/devguide/architecture/library-module.png" alt="组件" align="left" style="width:240px; margin-left:-40px;margin-right:10px" )
:marked
  Some modules are libraries of other modules.
  
  有些模块是其它模块的库。
  
  Angular itself ships as a collection of library modules called "barrels". 
  Each Angular library is actually a public façade over several logically related private modules.
  
  Angular本身就是用一组库模块的形式发布的，我们称之为“封装桶(barrel)”。
  每个Angular库实际上是一个公开的外观层（façade），囊括了许多逻辑上相关的私有模块。
  
  The `angular2/core` library is the primary Angular library module from which we get most of what we need.
  
  `angular2/core`库是主要的Angular库模块，从这里我们能获得所需的大部分东西。
  <br clear="all">
  
  There are other important Angular library modules too such as `angular2/common`, `angular2/router`, and `angular2/http`.
  
  还有其它重要的Angular库，比如`angular2/common`, `angular2/router` 和 `angular2/http`。
.l-sub-section
  :marked
     Learn more about how Angular organizes and distributes modules 
     in "[Modules, barrels and bundles](https://github.com/angular/angular/blob/master/modules/angular2/docs/bundles/overview.md)".  
     
     要学习Angular如何组织和分发模块的知识，参见"[模块、封装桶(barrel)和捆绑包(bundle)](https://github.com/angular/angular/blob/master/modules/angular2/docs/bundles/overview.md)"
:marked
  We import what we need from an Angular library module in much the same way. 
  For example, we import the Angular **`Component` *function*** from the *angular2/core* module like this:
  
  我们从Angular库模块中导入的方式基本上都是如此。
  比如，我们从 *angular2/core* 中导入Angular **`Component` *函数* ** 的代码是这样的：
+makeExample('architecture/ts/app/app.component.ts', 'import')(format=".")
:marked
  Compare that syntax to our previous import of `AppComponent`.
  
  比较一下它和前面导入`AppComponent`时的语法。
+makeExample('architecture/ts/app/main.ts', 'import')(format=".")
:marked
  Notice the difference? 
  In the first case, when importing from an Angular library module,
  the import statement refers to the bare module name, `angular2/core`, *without a path prefix*.
  
  注意到不同之处了吗？
  前面的方式中，当从Angular库模块中导入时，import语句引用的是一个裸模块名 —— `angular2/core` —— *没有路径前缀* 。
  
  When we import from one of *our* own files, we prefix the module name with the file path.
  In this example we specify  a relative file path (./). That means the
  source module is in the same folder (./) as the module importing it.
  We could path up and around the application folder structure if the source module were somewhere else.
  
  当我们从 *自己的* 文件中导入时，模块名中带有前缀，在这个例子中，是一个相对路径（./）。这表示源模块位于与导入它的模块相同的目录中（./）。
  如果源模块位于其它位置的话，我们还可以向上引用应用目录结构中的任意路径（../../../somewhere/）。
.l-sub-section
  :marked
    We import and export in the ECMAScript 2015 (ES2015) module syntax. 
    Learn more about that syntax [here](http://www.2ality.com/2014/09/es6-modules-final.html)
    and many other places on the web.
    
    我们导入和导出使用的是ECMAScript 2015 (ES2015)的语法。
    要学习更多关于此语法的知识，参见[这里](http://www.2ality.com/2014/09/es6-modules-final.html)，也可以在网上的很多地方找到。
    
    The infrastructure *behind* module loading and importing is an important subject.
    But it's a subject outside the scope of this introduction to Angular. 
    While we're focused on our application, *import* and *export*
    is about all we need to know.
    
    关于模块加载和导入背后的基础设施，是一个很重要的话题。
    但是，这个话题在介绍Angular的范围之外。在我们聚焦于讲解应用的时候，知道 *import* 和 *export* 就足够了。
:marked
  The key take-aways are:
  
  要知道的关键是：
  * Angular apps are composed of modules.
  * Angular应用是由模块组成的。
  * Modules export things &mdash; classes, function, values &mdash; that other modules import.
  * 模块导出一些东西 —— 类，函数，值，供其它模块导入。
  * We prefer to write our application as a collection of modules, each module exporting one thing.
  * 我们喜欢把应用写成一组模块，每个模块只导出一个东西。
  
  The first module we write will most likely export a component.
  
  我们写的第一个模块很可能是导出一个组件。
.l-main-section
<a id="component"></a>
:marked
  ## The Component
  ## 组件
figure
  img(src="/resources/images/devguide/architecture/hero-component.png" alt="组件" align="left" style="width:200px; margin-left:-40px;margin-right:10px" )
:marked
  A **Component** controls a patch of screen real estate that we could call a *view*. 
  The shell at the application root with navigation links, that list of heroes, the hero editor ... 
  they're all views controlled by Components.
  
  **组件** 控制屏幕中的补丁大的一小块儿地方，我们称之为 *视图* 。
  应用的“外壳”包括一些导航链接、一个英雄列表、英雄编辑器…… 它们都是被组件控制的视图。
  
  We define a Component's application logic - what it does to support the view - inside a class.
  The class interacts with the view through an API of properties and methods. 
  
  我们定义了一个组件的应用逻辑 —— 它被用来为视图提供支持 —— 放在类中。
  组件用一些由属性和方法组成的API与视图交互。
  
  <a id="component-code"></a>
  A `HeroListComponent`, for example, might have a `heroes` property that returns an array of heroes
  that it acquired from a service.
  It might have a `selectHero()` method that sets a `selectedHero` property when the user clicks on a hero from that list.
  It might be a class like this:
  
  <a id="component-code"></a>
  比如，`HeroListComponent`组件，可能有一个`heroes`属性，它返回一个英雄的数组，这个数据是从服务中取得的。
  它还可能有一个`selectHero()`方法，用来在用户从列表中点击一个英雄时设置`selectedHero`属性。
  它可能是像这样的一个类：

+makeExample('architecture/ts/app/hero-list.component.ts', 'class', 'app/hero-list.component.ts')
:marked
  Angular creates, updates, and destroys components as the user moves through the application.
  The developer can take action at each moment in this lifecycle through optional [Lifecycle Hooks](lifecycle-hooks.html).
  
  当用户在这个应用中“移动”时，Angular会创建、更新、销毁组件。
  开发人员还可以通过[生命周期钩子](lifecycle-hooks.html)在组件生命周期的每个时间点做出自己的处理。
.l-sub-section
  :marked
    We're not showing those hooks in this example 
    but we are making a mental note to find out about them later.
    
    我们不会在这个例子中展示这些钩子，先在脑子中留个记号，将来再翻出来讲。
    
    We may wonder who is calling that constructor? Who provides the service parameter?
    For the moment, have faith that Angular will call the constructor and deliver an
    appropriate `HeroService` when we need it.

    我们可能会好奇，谁调用那个构造函数？谁为服务提供参数？
    现在，只要相信Angular就行了，它会去调用构造函数，并且在我们需要的时候交给我们一个合适的`HeroService`实例。
 
.l-main-section
<a id="template"></a>
:marked
  ## The Template
  ## 模板
figure
  img(src="/resources/images/devguide/architecture/template.png" alt="模板" align="left" style="width:200px; margin-left:-40px;margin-right:10px" )
:marked
  We define a Component's view with its companion **template**. A template is a form of HTML
  that tells Angular how to render the Component.
  
  我们通过伴随它的 **模板** 来定义组件的视图。模板是HTML的一种形式，用来告诉Angular如何渲染组件。

  A template looks like regular HTML much of the time ... and then it gets a bit strange. Here is a
  template for our `HeroList` component.
  
  基本上，模板看起来很像标准HTML……当然也略有一些奇怪的地方。下面是我们`HeroList`组件的一个模板。
+makeExample('architecture/ts/app/hero-list.component.html',null,'app/hero-list.component.html')
:marked
  We recognize `<h2>` and  `<div>`. 
  But there's other markup that no one told us about in school.
  What are `*ngFor`, `{{hero.name}}`, `(click)`, `[hero]`, and `<hero-detail>`?
  
  我们认得`<h2>`和`<div>`。
  但有一些其他的标签/属性是我们在学校中从没有听说过的。
  什么是`*ngFor`、`{{hero.name}}`、`(click)`、`[hero]`和`<hero-detail>`？
  
  These are examples of Angular's [template syntax](template-syntax.html). 
  We will grow accustomed to that syntax and may even learn to love it.
  We'll begin to explain it in a moment.
  
  这些是Angular [模板语法](template-syntax.html) 的例子。
  我们会逐步习惯这些语法，甚至会学着爱上它。
  一会儿我们再解释它。
  
  Before we do, focus attention on the last line. 
  The `<hero-detail>` tag is a custom element representing the `HeroDetailComponent`.
  
  在我们开始前，注意最后那行。
  `<hero-detail>`是一个自定义元素的标签，用来表示`HeroDetailComponent`组件。
  
  The `HeroDetailComponent` is a *different* component than the `HeroListComponent` we've been reviewing.
  The `HeroDetailComponent` (code not shown) presents facts about a particular hero, the
  hero that the user selects from the list presented by the `HeroListComponent`.
  The `HeroDetailComponent` is a **child** of the `HeroListComponent`.
  
  `HeroDetailComponent`是和我们审视过的`HeroListComponent` *不同* 的组件。
  `HeroDetailComponent`（未展示代码）展现一个特定英雄的情况，这个英雄是用户从`HeroListComponent`所展示的列表中选择的。
  `HeroDetailComponent`是`HeroListComponent`的 *子组件* 。

figure
  img(src="/resources/images/devguide/architecture/component-tree.png" alt="组件树" align="left" style="width:300px; margin-left:-40px;margin-right:10px" )
:marked
  Notice how `<hero-detail>` rests comfortably among the HTML elements we already know. 
  We can mix ... and will mix ... our custom components with native HTML in the same layouts.
  
  注意：`<hero-detail>`是多么和谐的出现在我们已经知道的那些HTML元素中。
  我们在同一个布局中，可以混合……而且还将混合……我们的自定义组件与原生HTML。
  
  And in this manner we can and will compose complex component trees to build out our richly featured application.
  
  在这种方式下，我们能而且将会组合出复杂的组件树，来构建我们那些丰富多彩的应用。
<br clear="all">

.l-main-section
<a id="metadata"></a>
:marked
  ## Angular Metadata
  ## Angular元数据
figure
  img(src="/resources/images/devguide/architecture/metadata.png" alt="元数据" align="left" style="width:150px; margin-left:-40px;margin-right:10px" )
:marked
<p style="padding-top:10px">Metadata tells Angular how to process a class.</p>
<p style="padding-top:10px">元数据告诉Angular如何处理一个类。</p>
<br clear="all">
:marked
  [Looking back](#component-code) at the `HeroListComponent`, we see that it's just a class.
  There is no evidence of a framework, no "Angular" in it at all.
  
  [回头看看](#component-code)`HeroListComponent`，我们就明白，它只是一个类。
  毫无框架的迹象，里面完全没有出现"Angular"。
  
  In fact, it really is *just a class*. It's not a component until we *tell Angular about it*.
  
  实际上，它真的只是一个类。直到我们 *告诉Angular这一点* ，否则就没有组件。
  
  We tell Angular that `HeroListComponent` is a component by attaching **metadata** to the class.
  
  通过把 **元数据** 附加到类，我们告诉Angular：`HeroListComponent`是个组件。
  
  The easy way to attach metadata in TypeScript is with a **decorator**. 
  Here's some metadata for `HeroListComponent`:
  
  TypeScript中，附加元数据的简单方式是 **装饰器(decorator)** 。
  下面就是`HeroListComponent`的一些元数据。
+makeExample('architecture/ts/app/hero-list.component.ts', 'metadata', 'app/hero-list.component.ts (元数据)')
:marked
  Here we see the `@Component` decorator which (no surprise) identifies the class
  immediately below it as a Component class.
  
  这里我们看到`@Component`装饰器（理所当然的）标记出紧跟着它的这个类是一个组件类。
  
  A decorator is a function. Decorators often have a configuration parameter. 
  The `@Component` decorator takes a required configuration object with the
  information Angular needs to create and present the component and its view.
  
  装饰器是一个函数。装饰器通常还有配置参数。
  `@Component`装饰器可以带一个配置对象，这些信息会被Angular用来创建和展示组件及其视图。
  
  Here we see a few of the possible `@Component` configuration options:
  
  * `selector` - a css selector that tells Angular to create and insert an instance of this component 
  where it finds a `<hero-list>` tag in *parent* HTML. 
  If the template of the application shell (a Component) contained
<div style="margin-left:30px">
code-example(language="html").
    &lt;hero-list>&lt;/hero-list>
</div>  
:marked
  >Angular inserts an instance of the `HeroListComponent` view between those tags.
  
  * `templateUrl` - the address of this component's template which we showed [above](#template).
  
  * `directives` - an array of the Components or Directives that *this* template requires.
  We saw in the last line of our template that we expect Angular to insert a `HeroDetailComponent`
  in the space indicated by `<hero-detail>` tags. 
  Angular will do so only if we mention the `HeroDetailComponent` in this `directives` array.
  
  * `providers` - an array of **dependency injection providers** for services that the component requires.
  This is one way to tell Angular that our component's constructor requires a `HeroService` 
  so it can get the list of heroes to display. We'll get to dependency injection in a moment.
figure
  img(src="/resources/images/devguide/architecture/template-metadata-component.png" alt="Metadata" align="left" style="height:200px; margin-left:-40px;margin-right:10px" )
:marked
  The `@Component` function takes the configuration object and turns it into metadata that it attaches
  to the component class definition. Angular discovers this metadata at runtime and thus knows how to do "the right thing".
  
  The template, metadata, and component together describe the view.

  We apply other metadata decorators in a similar fashion to guide Angular behavior. 
  The `@Injectable`, `@Input`, `@Output`, `@RouterConfig` are a few of the more popular decorators
  we'll master as our Angular knowledge grows.
<br clear="all">
:marked
  The architectural take-away is that we must add metadata to our code
  so that Angular knows what to do.

.l-main-section
<a id="data-binding"></a>
:marked
  ## Data Binding
  Without a framework, we would be responsible for pushing data values into the HTML controls and turning user responses
  into actions and value updates. Writing such push/pull logic by hand is tedious, error-prone and a nightmare to
  read as the experienced jQuery programmer can attest.
figure
  img(src="/resources/images/devguide/architecture/databinding.png" alt="Data Binding" style="width:220px; float:left; margin-left:-40px;margin-right:20px" )
:marked
  Angular supports **data binding**, 
  a mechanism for coordinating parts of a template with parts of a component.
  We add binding markup to the template HTML to tell Angular how to connect both sides.
  
  There are four forms of data binding syntax. Each form has a direction - to the DOM, from the DOM, or in both directions -
  as indicated by the arrows in the diagram.
<br clear="all">
:marked
  We saw three forms of data binding in our [example](#template) template:
+makeExample('architecture/ts/app/hero-list.component.1.html', 'binding', 'app/hero-list.component.html (excerpt)')(format=".")
:marked
  * The {{hero.name}} "[interpolation](displaying-data.html#interpolation)" 
  displays the component's `hero.name` property value within the `<div>` tags.
  
  * The `[hero]` [property binding](template-syntax.html#property-binding) passes the `selectedHero` from
  the parent `HeroListComponent` to the `hero` property of the child `HeroDetailComponent`.
  
  * The `(click)` [event binding](user-input.html#click) calls the Component's `selectHero` method when the user clicks
  on a hero's name

  **Two-way data binding** is an important fourth form
  that combines property and event binding in a single notation using the `ngModel` directive. 
  We didn't have a two-way binding in the `HeroListComponent` template; 
  here's an example from the `HeroDetailComponent` template (not shown):

+makeExample('architecture/ts/app/hero-detail.component.html', 'ngModel')(format=".")
:marked
  In two-way binding, a data property value flows to the input box from the component as with property binding.
  The user's changes also flow back to the component, resetting the property to the latest value,
  as with event binding.
  
  Angular processes *all* data bindings once per JavaScript event cycle, 
  depth-first from the root of the application component tree. 
figure
  img(src="/resources/images/devguide/architecture/component-databinding.png" alt="Data Binding" style="float:left; width:300px; margin-left:-40px;margin-right:10px" )
:marked
  We don't know all the details yet
  but it's clear from these examples that data binding plays an important role in communication 
  between a template and its component ...
<br clear="all">  
figure
  img(src="/resources/images/devguide/architecture/parent-child-binding.png" alt="Parent/Child binding" style="float:left; width:300px; margin-left:-40px;margin-right:10px" )
:marked
  ... ***and*** between parent and child components
<br clear="all">

.l-main-section
<a id="directive"></a>
:marked
  ## The Directive
figure
  img(src="/resources/images/devguide/architecture/directive.png" alt="Parent child" style="float:left; width:150px; margin-left:-40px;margin-right:10px" )
:marked
  Our Angular templates are *dynamic*. When Angular renders them, it transforms the DOM 
  according to the instructions given by a **directive**.
  
  A directive is a class with directive metadata. In TypeScript we'd apply the `@Directive` decorator
  to attach metadata to the class.
<br clear="all">
:marked
  We already met one form of directive: the component. A component is a *directive-with-a-template*
  and the `@Component` decorator is actually a `@Directive` decorator extended with template-oriented features.

.l-sub-section
  :marked
    While the **component is technically a directive**, 
    it is so distinctive and central to Angular applications that we chose
    to separate the component from the directive in our architectural overview.
:marked
  There are two *other* kinds of directives as well that we call "structural" and "attribute" directives.
  
  They tend to appear within an element tag like attributes, 
  sometimes by name but more often as the target of an assignment or a binding.
  
  **Structural** directives alter layout by adding, removing, and replacing elements in DOM.
  
  We see two built-in structural directives at play in our [example](#template) template:
+makeExample('architecture/ts/app/hero-list.component.1.html', 'structural')(format=".")
:marked
  * [`*ngFor`](displaying-data.html#ngFor) tells Angular to stamp out one `<div>` per hero in the `heroes` list.
  * [`*ngIf`](displaying-data.html#ngIf) includes the `HeroDetail` component only if a selected hero exists.
  
  **Attribute** directives alter the appearance or behavior of an existing element. 
  In templates they look like regular HTML attributes, hence the name.
  
  The `ngModel` directive, which implements two-way data binding, is an example of an attribute directive.
+makeExample('architecture/ts/app/hero-detail.component.html', 'ngModel')(format=".")
:marked
  It modifies the behavior of an existing element (typically an `<input>`) 
  by setting its display value property and responding to change events.
  
  Angular ships with a few other directives that either alter the layout structure 
  (e.g. [ngSwitch](template-syntax.html#ngSwitch))
  or modify aspects of DOM elements and components 
  (e.g. [ngStyle](template-syntax.html#ngStyle) and [ngClass](template-syntax.html#ngClass)).
  
  And of course we can write our own directives.

.l-main-section
<a id="service"></a>
:marked
  ## The Service
figure
  img(src="/resources/images/devguide/architecture/service.png" alt="Service" style="float:left; margin-left:-40px;margin-right:10px" )
:marked
  "Service" is a broad category encompassing any value, function or feature that our application needs.
  
  Almost anything can be a service. 
  A service is typically a class with a narrow, well-defined purpose. It should do something specific and do it well.
<br clear="all">
:marked
  Examples include:
  * logging service
  * data service
  * message bus
  * tax calculator
  * application configuration
  
  There is nothing specifically *Angular* about services. Angular itself has no definition of a *service*. 
  There is no *ServiceBase* class.
  
  Yet services are fundamental to any Angular application. 
  
  Here's an example of a service class that logs to the browser console
+makeExample('architecture/ts/app/logger.service.ts', 'class', 'app/logger.service.ts (class only)')(format=".")
:marked
  Here's a `HeroService` that fetches heroes and returns them in a resolved [promise](http://exploringjs.com/es6/ch_promises.html). 
  The `HeroService` depends on the `LoggerService` and another `BackendService` that handles the server communication grunt work.
+makeExample('architecture/ts/app/hero.service.ts', 'class', 'app/hero.service.ts (class only)')(format=".")
:marked
  Services are everywhere. 

  Our components are big consumers of services. They depend upon services to handle most chores. 
  They don't fetch data from the server, they don't validate user input, they don't log directly to the console. 
  They delegate such tasks to services.
  
  A component's job is to enable the user experience and nothing more. It mediates between the view (rendered by the template)
  and the application logic (which often includes some notion of a "model").  A good component presents
  properties and methods for data binding. It delegates everything non-trivial to services.

  Angular doesn't *enforce* these principles. 
  It won't complain if we write a "kitchen sink" component with 3000 lines.
  
  Angular does help us *follow* these principles by making it easy to factor our
  application logic into services and make those services available to components through *dependency injection*.

.l-main-section
<a id="dependency-injection"></a>
:marked
  ## Dependency Injection
figure
  img(src="/resources/images/devguide/architecture/dependency-injection.png" alt="Service" style="float:left; width:200px; margin-left:-40px;margin-right:10px" )
:marked
  "Dependency Injection" is a way to supply a new instance of a class 
  with the fully-formed dependencies it requires. Most dependencies are services.
  Angular uses dependency injection to provide new components with the services they need.
<br clear="all">
:marked
  In TypeScript, Angular can tell which services a component needs by looking at the types of its constructor parameters.
  For example, the constructor of our `HeroListComponent` needs the `HeroService`:
+makeExample('architecture/ts/app/hero-list.component.ts', 'ctor', 'app/hero-list.component (constructor)')(format=".")
:marked
  When Angular creates a component, it first asks an **Injector** for
  the services that the component requires. 
  
  An `Injector` maintains a container of service instances that it has previously created.
  If a requested service instance is not in the container, the injector makes one and adds it to the container
  before returning the service to Angular. 
  When all requested services have been resolved and returned, 
  Angular can call the component's constructor with those services as arguments.
  This is what we mean by *dependency injection*.
  
  The process of `HeroService` injection looks a bit like this:
figure
  img(src="/resources/images/devguide/architecture/injector-injects.png" alt="Service" )
:marked
  If the `Injector` doesn't have a `HeroService`, how does it know how to make one?
  
  In brief, we must have previously registered a **provider** of the `HeroService` with the `Injector`.
  A provider is something that can create or return a service, typically  the service class itself.
  
  We can register providers at any level of the application component tree.
  We often do so at the root when we bootstrap the application so that
  the same instance of a service is available everywhere.
+makeExample('architecture/ts/app/main.ts', 'bootstrap','app/main.ts (excerpt)')(format=".")
:marked
  Alternatively, we might register at a component level ...
+makeExample('architecture/ts/app/hero-list.component.ts', 'providers','app/hero-list.component.ts (excerpt)')(format=".")
:marked
  ... in which case we get a new instance of the
  service with each new instance of that component.
  
  We've vastly over-simplified dependency injection for this overview.
  We can learn the full story in the [Dependency Injection](dependency-injection.html) chapter.
  
  The points to remember are:
  * dependency injection is wired into the framework and used everywhere.<br><br>
  * the `Injector` is the main mechanism.
    * an injector maintains a *container* of service instances that it created.
    * an injector can create a new service instance using a *provider*.
  * a *provider* is a recipe for creating a service.
 
  * we register *providers* with injectors.

<a id="other-stuff"></a>  
.l-main-section
:marked
  ## Wrap up
  We've learned just a bit about the eight main building blocks of an Angular application
  
  1. [Module](#module)   
  1. [Component](#component)
  1. [Template](#template)
  1. [Metadata](#metadata)
  1. [Data Binding](#data-binding)
  1. [Service](#service)
  1. [Directive](#directive)
  1. [Dependency Injection](#dependency-injection)
  
  That's a foundation for everything else in an Angular application
  and it's more than enough to get going.
  But it doesn't include everything we'll need or want to know.
    
<a id="other-stuff"></a>  
.l-main-section
:marked
  ## The Other Stuff
  
  Here is a brief, alphabetical list of other important Angular features and services. 
  Most of them are covered in this Developers Guide (or soon will be):
  
  >**Animations** - A forthcoming animation library makes it easy for developers to animate component behavior
  without deep knowledge of animation techniques or css.
    
  >**Bootstrap** - A method to configure and launch the root application component.
  
  >**Change Detection** - Learn how Angular decides that a component property value has changed and 
  when to update the screen. 
  Learn how it uses **zones** to intercept asynchronous activity and run its change detection strategies. 
  
  >**[Component Router](router.html)** - With the Component Router service, users can navigate a multi-screen application 
  in a familiar web browsing style using URLs.
  
  >**Events** - The DOM raises events. So can components and services. Angular offers mechanisms for
  publishing and subscribing to events including an implementation of the [RxJS Observable](https://github.com/zenparsing/es-observable) proposal.
  
  >**[Forms](forms.html)** - Support complex data entry scenarios with HTML-based validation and dirty checking.
  
  >**HTTP** - Communicate with a server to get data, save data, and invoke server-side actions with this Angular HTTP client.
  
  >**[Lifecycle Hooks](lifecycle-hooks.html)** - We can tap into key moments in the lifetime of a component, from its creation to its destruction, 
  by implementing the "Lifecycle Hook" interfaces.
  
  >**[Pipes](pipes.html)** - Services that transform values for display. 
  We can put pipes in our templates to improve the user experience. For example,
  this `currency` pipe expression,
<div style="margin-left:40px">
code-example(language="javascript" linenumbers=".").
  price | currency:'USD':true
</div>
:marked
  >displays a price of "42.33" as `$42.33`.
  
  >**[Testing](../testing/index.html)** - Angular provides a testing library for "unit testing" our application parts as they
  interact with the Angular framework.