Sencha-逻辑-MVC（管理与依赖） (官网文档翻译6)

有两个主要的地方，依赖关系可以定义在煎茶触摸应用程序 - 应用程序本身或内部应用程序类。本指南给出了一些建议，如何以及在何处声明，在您的应用程序的依赖关系。

应用程序依赖

当你创建一个MVC应用程序，您的的Ext.application为您提供了一个方便的方法：模型，视图，控制器，存储和应用程序使用的配置文件，指定。下面是一个例子：

Ext.application({
name:'MyApp',

views:['Login'],
models:['User'],
controllers:['Users'],
stores:['Products'],
profiles:['Phone','Tablet']});

这5个配置选项，方便的方式来加载的文件，应用程序通常包括 - 模型，视图，控制器，存储和配置文件的类型。指定这些配置意味着你的应用程序会自动载入下列文件：

app/view/Login.js

app/model/User.js

app/controller/Users.js

app/store/Products.js

app/profile/Phone.js

app/profile/Tablet.js

在被载入，上面的例子是相当于手动定义的依赖这样的：

Ext.require(['MyApp.view.Login','MyApp.model.User','MyApp.controller.Users','MyApp.store.Products','MyApp.profile.Phone','MyApp.profile.Tablet']);

当您添加到您的应用程序的多个类，这些配置都变得越来越有用，帮助您避免输入完整的类名，每一个文件。但是，请注意，这些配置三个以上只是加载文件。以及加载的文件，他们做到以下几点：

配置文件 [b]profiles[/b] -每个配置文件实例化，并确定它是否应该是积极的。如果是这样，个人的自己的依赖也加载

控制器 controllers-每个控制器加载后实例

店 [b]stores[/b] -每个实例存储，如果没有指定给它一个默认的存储ID

这句话的意思是，如果你想利用为您提供的便利MVC，你定义你的应用程序的依赖性时，应使用这些配置选项。

配置文件特定的依赖关系

使用设备配置文件时，很可能就意味着你有一些类，仅用于某些设备上。例如，你的应用程序的平板电脑版本可能包含更多的功能比手机版本，这通常意味着它需要更多的类加载。其他依存关系可以被指定在每个配置文件：

Ext.define('MyApp.profile.Tablet',{
extend:'Ext.app.Profile',

config:{
views:['SpecialView'],
controllers:['Main'],
models:['MyApp.model.SuperUser']},

isActive:function(){returnExt.os.is.Tablet;}});

现在发生了什么事就发生在这里是将要加载的每个配置文件中指定的依赖，无论是否是积极的个人资料。不同的是，即使他们已经加载，应用程序不知道做额外的处理，例如实例配置文件特定的控制器，如果配置文件是不活跃的。

这听起来可能违反直觉的 - 为什么下载类，不会被使用吗？我们这样做的原因是产生一个通用的生产版本，可以部署到任何设备，检测应该使用哪个配置文件，然​​后启动应用程序。另一种方法是为每个配置文件中创建自定义的构建，制定一个微器，可以检测的设备激活，然后下载该配置文件的代码。

虽然普遍的构建方法并不意味着你下载代码，你不需要在每个设备上，绝大多数的应用程序这无异于这么小的额外的大小，这是难以察觉的差异。对于非常大的应用程序的差异将变得更加明显，所以这是可能的，我们会重新审视这个问题后2.0。

嵌套依赖

对于较大的应用程序，这是常见的分裂到子文件夹中，以便保持该项目组织的模型，视图和控制器。这是特别真实的看法 - 这是前所未闻的大型应用程序，有超过一百个不同的视图类，因此它们组织到文件夹可以使维护变得更加简单。

要指定子文件夹中的依赖关系只用一个句号（“。”）到指定的文件夹：

Ext.application({
name:'MyApp',

controllers:['Users','nested.MyController'],
views:['products.Show','products.Edit','user.Login']});

在这种情况下，这5个文件将被加载：

app/controller/Users.js

app/controller/nested/MyController.js

app/view/products/Show.js

app/view/products/Edit.js

app/view/user/Login.js

请注意，我们可以混合和匹配在每个配置 - 每个模型，视图，控制器，个人资料或商店，你可以指定的类名的最后一部分（如果你按照的目录约定），或完整的类名。

外部依赖项

我们的应用程序外，我们可以指定应用程序的依赖性，完全合格的要加载的类。最常用的情况，这是多个应用程序之间共享的身份验证逻辑。也许你有几个应用程序通过一个共同的用户数据库登录，您要共享的，它们之间的代码。一个简单的方法来做到这一点是沿着你的应用程序文件夹中创建一个文件夹，然后添加它的内容作为您的应用程序的依赖项。

例如，让我们说，我们的共享登录的代码包含一个登录控制器，用户模型和一个登录表单视图。我们希望在我们的应用程序中使用所有这些：

Ext.Loader.setPath({'Auth':'Auth'});Ext.application({
views:['Auth.view.LoginForm','Welcome'],
controllers:['Auth.controller.Sessions','Main'],
models:['Auth.model.User']});

这将加载以下文件：

Auth/view/LoginForm.js

Auth/controller/Sessions.js

Auth/model/User.js

app/view/Welcome.js

app/controller/Main.js

前三个被装从我们的应用程序外，近两年从应用程序本身。请注意，我们仍然可以混合和匹配应用程序文件和外部的依赖文件。

需要注意的是，使我们只需要告诉装载机在哪里可以找到这些文件，这就是我们做的Ext.Loader.setPath上面的调用加载的外部依赖关系。在这种情况下，我们说的是装载机找到任何开始我们的“验证”文件夹内的'验证'命名空间的类。这意味着我们可以把我们共同验证码到我们的应用程序的应用程序文件夹旁边的框架将能弄清楚如何加载所有。

每个依赖所属

在决定要申报每个依赖的一般规则是保持你的类完全独立的。例如，如果你有一个观点，它包含几个其他的意见，你应该声明这些依赖关系内的视图类，而不是应用程序：

Ext.define('MyApp.view.Main',{
extend:'Ext.Container',

requires:['MyApp.view.Navigation','MyApp.view.MainList'],

config:{
items:[{
xtype:'navigation'},{
xtype:'mainlist'}]}});

这是最好的方式，，宣布这些依赖关系的原因有两个 - 让您的app.js清洁，并让您到可靠的需要您的MyApp.view.Main的，和知道它已经有了它的所有依存关系感到满意。另一种方法是在你的app.js列出所有你的观点这样的：

Ext.application({
views:['Main']});

思考这个问题的一个简单的方法是，的app.js只包含顶级意见。如果您使用Ext.create（'MyApp.view.SomeView）在你的应用程序中，视图可以被认为是顶级。如果视图是只作为一个子视图的另一个视图（作为与MyApp.view.Navigation和MyApp.view.MainList以上）构成的，它不属于app.js.

自1.x中的变化

在煎茶触摸1，依赖关系，通常是指定在控制器以及在Ext.application调用。虽然这提供了一些便利，但也掩盖了真正的系统的体系结构，再加视图，模型和商店也密切控制器。下面是你可以做在1.x：

//1.x code, deprecatedExt.regController('SomeController',{
views:['Login'],
models:['User'],
stores:['Products']});

这个定义的视图，模型和Ext.application商店里面是完全一样的，但也给了一些方便的方法来访问这些类在你的控制器。1.x中生成的2群功能-getLoginView（）和getUserModel（） -露出了的getStore（）函数，该函数返回一个引用到任何您在此控制器中定义的物料。在2.x版本中，这些功能不再存在，但它的易于使用的替代品。

在每种情况下在这里的第一行是指煎茶触摸1.x的，与第二行示出在2.x的方式：

//creating a view - 2.x uses the standardized Ext.create
this.getLoginView().create();
Ext.create('MyApp.view.Login');

//getting a Model - just type out the Model name (it's shorter and faster)
this.getUserModel();
MyApp.model.User;

//Ext.getStore can access any Store whereas the old
this.getStore only

//accessed those Stores listed in your Controller

this.getStore('Products');
Ext.getStore('Products');

移除这些功能的应用程序启动的加快，因为框架不再需要为每个模型生成一个函数，并查看在每个控制器中定义。这也意味着，MVC的约定相匹配的约定，其余的框架，从而更具可预测性API。