带包的主干架构

Question

我正在尝试选择最适合我的应用程序的主干架构。

我正在构建一个大型应用程序，它将由多个可以启用或禁用的组件或“包”组成。

为简单起见，假设我的单页应用程序是一个画廊，其中包含多个组件，例如照片库和视频库。

• 我的应用程序的任何“安装”都可以选择要加载的组件（“包”） - 视频、照片或两者
• 视频和照片库有一些通用的代码和抽象类。
• 我希望每个安装仅在单个（优化）文件中加载所需的组件 - 这意味着如果安装仅使用照片库，则不应加载视频库 - 以节省资源。

我研究了各种解决方案 - 例如 requireJs 及其 r 优化器、marionette 和 Lumbar，但每个解决方案都有一些缺点：*带有优化器或木偶的Requirejs - 我看不到如何将文件分组到软件包中 * lumbar-似乎确实可以解决我的大部分问题，但是我几乎找不到任何文档或社区支持（在此处几乎没有在Stackoverflow上提及）因此，我不知道我是否可以依靠它来进行大型软件项目。

Answer 1

我决定腰椎是去的方式。似乎它通过使用它的基于路由的模块加载，解决了我对仅加载“启用”包的所有需求，如下所述： http://addyosmani.github.io/backbone -fundamentals/#route - 基于模块加载 通过在Lumbar.json配置文件中声明每个模块，它将为每个定义的模块创建一个单独的组合的js文件 - 只有在匹配其路由时才会加载模块。 你可以看到如何在胸腔种子中进行： https：//github.com/walmartlabs/thorax-seed/blob/master/readme.md

Answer 2

嗯，这当然是主观的，你有很多选择，但也许一些关于你的选择的背景信息可以有所帮助，我会冒险推荐 Chaplin.

Marionette 它的优点有很多，包括它是作为 Github 上的开源项目开发的。它应该是非常轻量级的，听起来你的麻烦源于它故意限制的功能集。

Chaplin 是一个框架之上的 Backbone.js 图书馆，比如 Marionette 以及您的其他几个选择。两者都旨在简化单页 JavaScript 应用程序的开发。在此类应用程序中，客户端执行通常在服务器上执行的任务，例如将原始数据呈现为 HTML。

Backbone 它本身被设计为一个简约的库，而不是一个功能齐全的框架。 Backbone 只能提供JavaScript应用程序架构的基础。两个都 Marionette 和 Chaplin 出现是因为 Backbone 为现实世界的应用程序提供的结构太少。他们应对同样的问题。因此，两者之间有很多相似之处——也许比差异还多。

与木偶相比，卓别林更像是一个框架。它更加固执己见，并且在多个领域有更强大的惯例。它借鉴了 Ruby on Rails 等服务器端 MVC 框架的思想，遵循约定优于配置的原则。Chaplin 的目标是提供经过充分验证的指导方针和便利的开发环境。CoffeeScript 和 OOP

Chaplin 是用 CoffeeScript 编写的，CoffeeScript 是一种可以编译为 JavaScript 的元语言。然而，Chaplin 应用程序不必用 CoffeeScript 编写。最后，Chaplin 只是另一个 JavaScript 库。

使用 CoffeeScript 是 Chaplin 使应用程序开发更容易、更健壮的想法的一部分。CoffeeScript 执行 Douglas Crockford 的书《JavaScript – The Good Parts》中的指导原则。和 Marionette 一样，Chaplin 也提倡 ECMAScript 5 严格模式。

与 Backbone 的扩展功能相比，CoffeeScript 的类声明和基于类的继承更加紧凑。当 Marionette 试图绕过超级调用时，Chaplin 则拥抱方法重写并尝试使基于类的继承顺利工作。例如，如果您在派生类及其超类上声明事件处理程序，则两者都会应用。使用 CommonJS 或 AMD 进行模块化

Chaplin 要求您在 CommonJS 或 AMD 模块中构建 JavaScript 代码。每个模块都需要声明其依赖项，并可能导出一个值，例如构造函数或单个对象。在 Chaplin 中，一个文件通常包含一个类并定义一个模块。

通过将代码拆分为可重用的模块并以机器可读的方式声明依赖关系，可以自动加载和打包代码。

使用 AMD 并不容易，您需要熟悉 Require.js 等加载器和 r.js 等优化器。作为替代方案，您可以使用 CommonJS 模块格式和 Brunch 作为处理器。

Chaplin 提供了一个相当固定的核心应用程序结构。它处理应用程序中的主要流程。

The Application is the root class that starts the following parts
The Router replaces Backbone.Router
The Dispatcher starts and stops controllers when a route matches
The Layout is the top-level view that observes clicks on links

在 Chaplin, ，有一个定义所有路线的中心位置。路由指向控制器操作。例如，URL 模式 /cars/:id 指向 cars#show，即 CarsController 的 show 方法。

控制器是您创建模型的地方。它还负责创建主要内容区域的视图。因此，控制器通常代表应用程序界面的一个屏幕。

主要思想是 Chaplin 是一次性控制器。基本规则是：当另一个路由匹配时，当前控制器及其所有子级（模型、集合、视图）将被释放。即使路由指向同一控制器的另一个操作，控制器实例也会被释放并创建一个新实例。

当另一条路线匹配时扔掉对象是清理引用的简单而有效的规则。当然，有些对象需要保留在内存中以便以后重用。这 Chaplin.Composer 允许您以受控方式共享模型和视图。您需要明确地将它们标记为可重用。如果保存的对象在下一个控制器操作中没有重用，则会自动丢弃。

在一个 Chaplin 应用程序中，每个对象都应该是一次性的。全部 Chaplin 类有一个 dispose 方法，该方法将使对象变得不可用并切断所有联系。

JavaScript 编程的一个众所周知的规则是避免全局变量。卓别林试图执行这一最佳实践。类是隐藏在闭包作用域中的 CommonJS/AMD 模块。所有实例都应该是私有的。两个实例不应相互引用，除非它们密切相关，例如视图及其模型。

对象可以使用发布/订阅模式以解耦的方式进行通信。为此，Chaplin.Mediator 存在。中介器还可以用于全局共享选定的实例，例如用户对象。创建必要的属性后，中介对象将被密封，因此它不会成为应用程序的厨房水槽。

Chaplin 也强于 view management. 。它具有应用程序范围的命名区域和子视图管理。Chaplin 采用不同的方法来渲染视图并将它们附加到 DOM。视图可能有一个 autoRender 标志和一个容器选项。启用这些后，视图将在创建时呈现并自动附加到 DOM。您可以指定区域而不是容器，以便将视图附加到先前注册的区域。

在 Chaplin 除了应用程序范围的区域之外，没有像这样的抽象类 Marionette.Layout 和 Marionette.Region. 。在 Marionette 应用程序中，您通常会创建多个嵌套布局和区域。在 Chaplin 应用程序中，关键区域较少，并且直接在其中嵌套视图。当然，您可以创建可重用的视图，其行为类似于 Marionette.Layout, ，例如 ThreePaneView。