Question

我正在努力想出一个干净，可靠的方法来组织我的Backbone应用程序。我使用Requirejs，Handlebars和Requirejs Text插件来动态加载HTML视图。为简化起见，我们只是说该网站包含以下页面：

主页：显示产品集合

关于：静态页面

帐户包含帐户信息。购买的产品，允许各种更新。很多功能。有标签导航到不同的部分。

所以我要去一个将新页面加载到div中的SPA（＆＃39; .backbone-view＆＃39;）。我应该有一个带有el：$（＆＃39; .backbone-view＆＃39;）的通用AppView，当路由发生变化时调用，然后加载相应的模板？或者我应该有每个页面的视图（homeView，aboutView，accountView），所有这些都设置为骨干视图？

除此之外......除了产品之外我还需要一个模型吗？对于静态页面，我只需加载html模板即可。但对于产品，我需要调用产品集合，它会呈现每个产品视图，每个视图都与产品模型相关联。那很好......但是我在哪里初始化这些产品结构？当我路由到主页时，我在那里做吗？我有这个伪代码：

  routes: {
        '': 'home',
        'about': 'about',
        'my-account': 'myAccount',
        '*default': 'home'
    },

    'home': function() {
        // Grab template for home page

        // Load up products

        // Replace $('.backbone-view') with home page template populated with products
    },

    'about': function() {
        // Grab about template and replace $('.backbone-view') with its contents
    },

    'myAccount': function() {
        MIND EXPLOSION
    }

我认为一个大问题是我不清楚视图的目的......它们是否可以仅用于页面转换，还是应该总是附加一个模型？如果是前者，我至少需要一个AppView然后为每个页面查看，对吧？我迷失了我将委派每一步的地方......所以任何帮助都会受到赞赏。

感谢您的帮助！

Answer 1

以下是处理非常大的主干应用程序后的一些提示。它并非详尽无遗或最终......

分为两个目录

此外，当您运行构建任务时，它会将应用程序构建为可分发版本到build/或dist/目录中。可能使用Gulp或Grunt。

扩展骨干

您的整个应用程序将包含：

观点＆amp;子视图
路由器＆amp;子路由器
模型
集合

你应该扩展Backbone类，即使它们最初是空的。最有用的两个扩展是：

子视图（视图可以包含具有更多视图的views对象/函数，在删除父视图时会清除这些视图。名为model或collection的模型和集合会自动传递给子视图。
子路由器（很高兴为模块文件夹中的每个模块提供路由逻辑）

使用pod架构

在围绕自包含模块组织应用程序时，例如：

www/app/modules/home/router.js＆lt; - sub router，调用modules.js中的方法 www/app/modules/home/module.js＆lt; - 准备端点 - 更改布局，初始化视图＆amp;模型等 www/app/modules/home/views/...所有观点（也可以有子文件夹）
www/app/modules/home/templates/
www/app/modules/home/models/
www/app/modules/home/collections

根据观看次数和子视图开始查看您的应用

页面不仅包含一个视图。它可能会有一个特殊的布局＆＃34;视图和里面会有很多视图 - 一个将页面分成两半，一个分页，每个页面编号包含更多视图，一个视图包含每个表单元素和消息内部有很多子视图等等< / p>

您可以开始将视图视为遮蔽DOM树并进行逻辑划分 - 您认为可以在页面上重复使用的任何内容使其成为一个包（如果需要，它可以拥有自己的视图和模型/集合）

模型适用于任何数据和对数据执行的任何逻辑，如果视图显示来自server / api / database的任何内容，它通常会传递给视图，该视图会将所有或部分模型属性传递给模板。

如果显示信息的项目在列表中，那么集合将管理每个项目的每个模型。

与模特沟通

如果您发现自己想要从视图向另一个视图传达某些内容，请使用共享模型。视图应该尽可能地分离（它不应该知道它的父母）。

拥有应用状态

创建一个名为AppState的模型，使用触发器和侦听在应用程序之间进行广泛沟通。

拥有一个包文件夹（可选）

每当您在应用中遇到您认为可以重复使用的内容时，即使在其他未来的应用中也是如此，请创建一个包。这些通常会托管在他们自己的git repos上，你可以使用package.json或命令行将它们拉入项目中。

有一个文件夹，您可以在其中扩展应用间内容

为多个应用程序使用的模块提供扩展文件夹 - 例如你的骨干扩展可以到这里来。或者，如果您为表单创建了一个包，但想要专门为此应用程序执行某些操作，请在此处进行扩展。

e.g。 www/app/extensions/view.js
www/app/extensions/model.js
www/app/extensions/collection.js
www/app/extensions/buttons/link.js //从＆＃34;按钮扩展链接视图＆＃34;封装

<强>资产

我在公共app/文件夹中有一个www/文件夹的原因是我还可以在其中有一个资源文件夹用于字体和图像等：

www/assets/css
www/assets/images

注意：也许您想尝试将资源保留在模块文件夹中（与pod体系结构内联）。我之前没有这样做，但值得考虑。

<强>的index.html

通常，如果你使用CommonJS或AMD，你的index.html只是样板，没有实际的DOM元素，你可以在那里调用一个条目js文件。由于CommonJS必须编译，这就像<script src="/app.js"></script>，但对于AMD，它更像是：

<!--IF NOT BUILD-->
<script data-main="/app/config" src="/packages/require.js"></script>
<!--ELSE
<script src="/app.js"></script>
-->

因此，当在dev（非构建）中运行时，RequireJS将加载app/config.js但在构建时整个应用程序将在app.js中。有各种Grunt / Gulp构建任务，它们将为您执行类似上面的操作（显然条件语法只是组成）。

<强>布局

我会创建一个扩展extensions/layout.js的{{1}}，这将是一个简单的扩展，可以像普通的子视图（例如页眉和页脚），但也可以附加一个特殊的子视图查看（对于身体子视图）例如像extensions/view.js这样的方法。

我可能会创建一个名为layouts的模块，并且其中有一个目录setContentView(view)，其中包含一个包含页眉和页脚子视图的视图。然后到达索引路线将会发生如下情况：

modules/layout/default

<强>路由

我的应用程序路由器位于例如app/router.js => app/modules/home/router.js => app/modules/home/module.js@index => setContentView(view from app/modules/home/views/index.js)"可能有一些特殊的路由但很大程度上只是用一个指向子路由器的对象进行子路由：

www/app/router.js

我可以通过扩展普通的Backbone路由器来实现这一点（在你的扩展中注意，你需要在subRouters: { 'store-locator': StoreLocatorRouter, myaccount: MyAccountRouter, sitemap: SitemapRouter }中调用initSubRouters） -

initialize

project layout

app layout

骨干项目组织

1 个答案: