Question

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

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

为简单起见，我们可以说我的单页应用程序是一个包含多个组件的库，例如照片库和视频库。

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

我已经研究过各种解决方案 - 比如requireJs及其r优化器，木偶和Lumbar，但每个都有一些缺点： * RequireJS与优化器或木偶 - 我无法看到如何将文件分组到包中 * Lumbar - 似乎它确实解决了我的大多数问题，但我几乎找不到任何文档或社区支持（在StackOverflow上几乎没有提到）所以我不知道我是否可以依赖它来进行大型软件项目。 / p>

Answer 1

嗯，这肯定是主观的，你有很多选择，但也许你的一些选择的一些背景信息可能有所帮助，我会走出困境并推荐Chaplin。

Marionette有很多原因，包括它在Github上开发为开源项目。它意味着非常轻巧，听起来你的麻烦源于它故意限制的功能集。

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

Backbone本身被设计为一个极简主义的图书馆，而不是一个功能齐全的框架。 Backbone只能提供JavaScript应用程序架构的基础。 Marionette和Chaplin都出现了，因为Backbone为现实世界的应用提供了太少的结构。他们回应同样的问题。所以两者之间有很多相似之处 - 也许不仅仅是差异。

与木偶相比，卓别林更像是一个框架。它更具舆论性，并在若干领域有更强的公约。它采用了Ruby on Rails等服务器端MVC框架的思想，这些框架遵循约定优于配置原则。卓别林的目标是提供经过充分验证的指导方针和便利的开发环境。 CoffeeScript和OOP

Chaplin是用CoffeeScript编写的，这是一种编译为JavaScript的元语言。但是，Chaplin应用程序不必用CoffeeScript编写。最后，卓别林只是另一个JavaScript库。

使用CoffeeScript是卓别林的一部分，旨在使应用程序开发更容易，更健壮。 CoffeeScript执行Douglas Crockford的书“JavaScript - The Good Parts”的指南。像Marionette一样，Chaplin正在倡导ECMAScript 5严格模式。

使用CoffeeScript，与Backbone的扩展功能相比，类声明和基于类的继承更紧凑。虽然Marionette试图绕过超级呼叫，但卓别林采用方法覆盖并试图使基于类的继承顺利进行。例如，如果在派生类及其超类上声明事件处理程序，则将应用这两者。使用CommonJS或AMD进行模块化

卓别林要求您在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也很强大。它具有应用程序范围的命名区域和子视图管理。卓别林采用不同的方法渲染视图并将其附加到DOM。视图可能具有autoRender标志和容器选项。启用这些后，视图将在创建时呈现，并自动附加到DOM。您可以指定区域而不是容器，以便将视图附加到先前注册的区域。

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

Answer 2

我认为Lumbar是要走的路。好像它通过使用基于路由的模块加载解决了我只需加载“启用”软件包的所有需求，如下所述： http://addyosmani.github.io/backbone-fundamentals/#route-based-module-loading 通过在lumbar.json配置文件中声明每个模块，它将为每个定义的模块创建一个单独的组合js文件 - 并且仅在其路由匹配时才加载模块。您可以在thorax-seed中看到如何做到这一点： https://github.com/walmartlabs/thorax-seed/blob/master/README.md

骨干架构与包

2 个答案: