前言：
读英文文档总是很难的，非母语且专业化的长篇大论容易令人气馁和浮躁，从而导致学习效率低下。 翻译是一个好方法，把学习的需求转变成翻译的任务，强迫自己不仅要看进去、看得懂，而且还要字斟句酌，然后清晰明了的表达出来，这种在翻译中学习的成果无疑是最牢固的，最后你的译文还可以帮助别人。
这篇文章的英文原址是http://docs.sencha.com/touch/2-0/#!/guide/apps_intro
原文标题是：Intro to Applications with Sencha Touch 2（Sencha Touch 2 应用程序简介）。有意思的是，官方文档目录中给它的说明是 All about Applications（关于应用程序的一切） , 仔细读来你会发现这篇文章其实是Sencha Touch MVC的总纲，对于理解Sencha Touch的MVC模式意义重大，不得不读，所以我把它作为此系列翻译的第一篇文章。鉴于本人水平有限，翻译不当乃至谬误之处在所难免，还望大家不吝赐教。
这篇原创翻译首先发布在自己的博客上，后续更新也都会在第一时间发布上去，敬请关注。另外我还建了一个QQ群（群号213119459）以方便Sencha Touch爱好者交流，欢迎您的加入。
译文原地址：http://www.cnblogs.com/dowinning/archive/2012/02/14/2350303.html
Intro to Applications with Sencha Touch 2 Sencha Touch 2应用程序简介
注：为方便起见，文中所有出现 Sencha Touch 的地方均以 ST 简写替代。
Sencha Touch 2 is optimized around building applications that work across multiple platforms. To make the writing of applications as simple as possible, we provide a simple but powerful application architecture that leverages the MVC (Model View Controller) pattern. This approach keeps your code clean, testable and easy to maintain, and provides you with a number of benefits when it comes to writing your apps:
ST2 专为构建可跨多平台工作的（web）应用程序而优化。为尽可能的方便您编写应用程序，我们提供了一个虽简单但却强大的应用程序架构，它可以视作是对MVC（Model/模型、View/视图、Controller/控制器）模式的扩充。使用这种模式编写应用程序，不仅可以保证你的代码干净、便于测试、容易维护，还能得到如下好处：
?
History Support: full back button support inside your app, and any part of your app can be linked to
访问历史支持：你的应用将获得完整的后退按钮功能，其中的任意部分都可以被链接到
? Deep Linking: share deep links that open any screen in your app, just like linking to a web page
深度链接：如同以往链接到某一个web页面一样，深度链接可以打开你应用程序中的任意屏幕
? Device Profiles: easily customize your application's UI for phones, tablets and other devices while sharing all of the common code
设备配置文件：共享通用代码的同时，轻松为手机、平板电脑还有其他设备定制应用程序UI（用户界面）
Anatomy of an Application 应用程序结构解析
An Application is a collection of Models, Views, Controllers, Stores and Profiles, plus some additional metadata specifying things like application icons and launch screen images. ST 应用程序是一个由 Model、View、Controller、Store、Profile 组成的集合，外加一些额外指定的元数据，比如 icon 图标和启动界面显示的图片。
?
Models: represent a type of object in your app - for example an e-commerce app might have models for Users, Products and Orders
数据模型：在应用程序中表示一种数据模型，比如一个电子商务应用程序可能会有用户、产品、订单等不同的数据模型 ?
Views: are responsible for displaying data to your users and leverage the built in Components in Sencha Touch
视图：负责将数据展示给用户，并扩充 Sencha Touch 的内置组件。（译者注：你可以理解为用户界面的一个个组成部分） ?
Controllers: handle interaction with your application, listening for user taps and swipes and taking action accordingly
控制器：处理应用程序的交互，侦听用户的轻触、猛击（译者注：真实意思是长按？）等事件并做出相应的响应 ?
Stores: are responsible for loading data into your app and power Components like Lists and DataViews
数据存储器：负责把数据加载到你的应用并以列表（List）或者数据视图（DataView）等形式表现出来 ?
Profiles: enable you to easily customize your app's UI for tablets and phones while sharing as much code as possible
设备配置：可以使你为平板电脑和手机等不同设备，轻易定制应用程序用户界面，并尽可能多的共享代码
The Application is usually the first thing you define in a Sencha Touch application, and looks something like this:
Application 对象通常是你开发一个ST应用时需要定义的第一个东西，类似下面这样子：
Ext.application({ name: 'MyApp',
models: ['User', 'Product', 'nested.Order'],
views: ['OrderList', 'OrderDetail', 'Main'], controllers: ['Orders'],
launch: function() {
Ext.create('MyApp.view.Main'); } });
The name is used to create a single global namespace for your entire application, including all of its models, views, controllers and other classes. For example, an app called MyApp should have its constituent classes follow the
pattern MyApp.model.User, MyApp.controller.Users,MyApp.view.Main etc. This keeps your entire app under a single global variable so minimizes the chance of other code on the page conflicting with it.
如代码所示，application 构造参数中有个 name 属性，它为你的应用程序创建一个唯一命名空间，其下包含了该应用全部的 model、view、controller 还有其他 class（类），比如一个叫做 MyApp 的应用就应该遵循以下形式来组织：MyApp.model.User, MyApp.controller.Users, MyApp.view.Main 等，这可以保证你整个的应用程序都处在一个唯一全局变量下，从而最大限度降低代码冲突的可能性。
The Application uses the defined models, views and controllers configurations to automatically load those classes into your app. These follow a simple file structure convention - models are expected to be in the app/model directory, controllers in the app/controller directory and views inside the app/view directory - for
example app/model/User.js, app/controllers/Orders.js and app/view/Main.js.
应用程序会按照你在 application 构造函数中定义好的 models, views 和 controllers 属性成员来自动加载它们对应的 class（类）到当前应用，ST2 架构约定的文件结构如下：model 都放在 app/model 目录，controller 都放在 app/controller 目录，view 则放在 app/view 目录，比
如 app/model/User.js, app/controller/Orders.js, app/view/Main.js（译者注：原文中 Orders.js 文件的路径是错的，model、view、controller 这三个目录名称都没有 s ）
Note that one of the models we specified was different to the others - we specified the full class name (\configurations if we don't follow the normal naming conventions. See the Dependencies section of the Ext.app.Application docs for full details on how to specify custom dependencies.
注意 models 属性中有一个成员的定义跟其他不一样，(\，除了遵循上述的常规命名格式以外，我们还可以使用完整类名的方式来定义这些配置，换言之 application 构造函数中的 models、views、controllers 这些参数属性都可以用完整类名方式来定义，想了解更多关于如何定义依赖项的细节，请参见文章 Dependencies section of the Ext.app.Application docs （ Ext.app.Application 文档中的 Dependencies 章节）
Controllers 控制器
Controllers are the glue the binds an application together. They listen for events fired by the UI and then take some action on it. This helps to keep our code clean and readable, and separates the view logic from the control logic.
Controller（控制器）就像胶水一样粘合出一个完整的应用程序，它们侦听UI界面触发的事件，然后做出相应的动作，还能够让我们的代码更简洁，可读性好，从而把界面逻辑和控制逻辑隔离开来。
For example, let's say you require users to log in to your app via a login form. The view in this case is the form with all of its fields and other controls. A controller should listen to tap event on the form's submit button and then perform the authentication itself. Any time we deal with manipulating data or state, the controller should be the class that activates that change, not a view.
假如你需要用户通过一个 login 表单来登录你的应用程序，此时的 view（视图）就是这个包含了所有字段和其他元素的表单，而它的 controller（控制器）要做的就是侦听表单提交按钮的点触事件并进行身份验证，每次我们要处理数据或者状态的时候，这个 controller（控制器）才是应该起作用的类，而不是 view（视图）。
Controllers expose a small but powerful set of features, and follow a few simple conventions. Each Controller in your application is a subclass of Ext.app.Controller (though you can subclass existing Controllers, so long as it inherits from Ext.app.Controller at some point). Controllers exist in the MyApp.controller.* namespace - for example if your app had a Sessions controller it would be called MyApp.controller.Sessions and exist in the file app/controller/Sessions.js.
Controller（控制器）通过一些简单的约定，展示了一套虽小但却很强大的特性。应用程序的每一个 controller（控制器）都是 Ext.app.Controller 的一个子类，当然你也可以继承现有的 controller ，只要它也是继承自 Ext.app.Controller ，controller（控制器）都存在于 MyApp.controller.* 命名空间，例如你的应用有一个叫做 Sessions 的controller ，那么它的完整命名空间将会是 MyApp.controller.Sessions 并且被定义在 app/controller/Sessions.js 文件中。
Although each Controller is a subclass of Ext.app.Controller, each one is instantiated just once by the Application that loaded it. There is only ever one instance of each Controller at any one time and the set of Controller instances is managed internally by the Application. Using Application's controllers config (as we do above) loads all of the Controllers and instantiates them automatically.