八月陆陆续续将 Ben McCormick 讲解 Marionette 的系列六篇文章《Marionette: Explained》翻译和学习完成。首先非常感谢作者，给了像我这样的初涉前端应用程序的开发者一个比较全面完整的学习指引。
这六篇文章我还是以我一贯的风格，以略译的形式完成，略译不但不是意译，甚至是笔记式的改写，以自己的语言概念系统重新梳理一遍这些开发知识、技术和理论。
正所谓一百位教师就有一百种教学方法，在略译Ben的文章过程中，除了忽略部分过时的内容，我还以自己喜好的表述方式重组织过内容，并且使用了很多自己提炼的语言和概念。我的理由是，前端应用开发是块热土，各路英雄各举一器，到目前还没一个稳定成熟开发路法，教什么都不确定，如何教更是五花八门。
本文略译自《The Life of a Marionette View》
有过前端经验的人都了解，在构建单页面应用程序时，页面常常有一些UI组件需要被动态替换，要确保它们被正确创建、使用和销毁，不然产生内存问题。所以，管理页面上的「UI组件的置换」是很重要的任务，Marionette 在View基类中增加了“生命周期”的事件“勾子”，达到了简化管理「UI组件的置换」的任务。
本文略译自《Building Complex Layouts With Marionette.js》，主要介绍——交互页面的布局需求。
当我们开发一支较复杂的web交互应用程序，首先摆在设计师的第一个问题（之一）是，如何规划交互页面的内容结构和位置布局（structure and layout of your application）。大多数交互应用程序有这样的布局结构：
静态区域则比较容易，动态区域则需要某种管理功能，能内容调入调出（swapping out）。在Backbone里，怎么实现布局呢？尤其是有动态区域的布局结构？
本文略译自《The Case For Marionette.js》
Backbone.js不是一个完整的应用框架，用它来开发「大型前端应用」是不容易的。 Backbone 的设计思想是很棒的，它的极简设计提供极大的自由和灵活性，能满足各种开发场景，然而这种极简设计涉及的面变得很宽而没有针对性，结果，当你用Backbone开发大型应用时，相对于 Angular 或 Ember 这样的”不简单不灵活的”应用框架（opinionated frameworks），反而失去了效率上的优势。因为大型应用固有的很多任务和开发困难（具体什么困难？[注]），你都得自己（自由）判断解决，要么给 Backbone 添加第三方插件，要么自己实现。
注：嵌套的V，复合的M等，当应用scale up，需更多「构件」——更粗粒度的工作对象——提高开发效率，和降低维护的成本
Backbone 要用来开发大型应用，需要引入更多的构件工具，或完整的应用框架，本文介绍最流行的一支 Marionette.js
本文略译自《Staying DRY with Marionette Behaviors》
Backbone 提供的构件过于“简陋”，开发者普遍抱怨Backbone的一点，就是要写太多重复的代码（boilerplate）——不断写UI事件逻辑代码，业务控制逻辑代码。
削减boilerplate code，是Marionette的目标之一。而在之前的「高级V基类」的基础之上，Marionette还提供一个通用基类——the Behavior class，进一步削减重复的代码，让你的代码更加的DRY。
EM：V的代码复杂到居然可以「再度的抽象」
EM：理解和应用Behavior的前提，是对V有深刻全面的了解
Marionette Behaviors 类是对「通用的UI逻辑代码」的抽象，故它可“植入”你的View中，实现复用。当你发现在多个V类中出现类似的行为代码，那么你可用Behaviors对它进行抽象，来降低boilerplate。
在开始介绍Behaviors API前，我们先看一个实例。
p.s. 原文标题：交互功能单元制作的核心任务之一——将业务数据连接上交互界面
开发JS APP的任务可归纳为主要的三项：制作V，用V组建PAGE，用PAGE组建APP。其中「制作V」作为交互功能的独立单元，是最基本，也是最核心的任务之一。「制作V」的一项关键任务，就是将业务数据M“连接”上V。任何V都是要 render 的，因为这是它的形式核心——计算对象的输出，但有一大部分的V则需要「先」绑定业务数据，binding 数据，是前render任务。
本文略译自《Marionette Explained: Connecting Data to Your Views》，介绍Marionette将M“连接”上V的方式。
Backbone Radio是什么，为什么要学习和使用它？这个问题，我们先看看官方的介绍：
Backbone.Radio为开发Backbone应用提供了额外的通信模式（messaging patterns）；
Backbone 自带有一个事件通信系统（event system）——实现广播订阅模式的Backbone.Events。Backbone.Radio 则增加两项额外的功能：
- 第一个是Requests，一种request-reply的通信模式；
- 第二个是Channels，一种划分通信逻辑边界的机制，可将程序的通信划分为不同的逻辑空间（namespaces）。
我们再看看 Marionette 的解释：
In short, Radio is a global, namespaced, message bus system designed to allow two otherwise unrelated objects to communicate and share information.
简单的说，Radio是一个全局的、可划分逻辑通信空间的通信总线模块（message bus system ），目的是为了让程序中两个不太相关的对象进行通信和共享资源。
以上对Backbone Radio的解释，对于实际开发过Backbone/Marionette应用的人来说，是比较明显的，但是对于只了解Backbone，或者初学者来说，则比较难理解。什么是通信模式？总线是什么？通信空间？两个不相关的对象？
按照「方案、任务、技术和理论」的学习模式，以上官方解释只是Backbone Radio作为一种工具的技术一面，我们需要更多的在任务、和理论原律方面的解释，才能丰富的认识这个工具，掌握这个工具。下面略译《Building Modular Web Apps With Backbone.Radio》一文，补充这方面的信息。
本文略译自《Backbone.js Basics: Bringing an App to Life with Events》。
在前一篇教程里，我们尝试了使用Backbone.js开发前端应用程序，开发一个小型商店库存管理应用（有关冲浪板数据的）。根据应用的需要，我们尝试了为业务数据创建了模型（models），模型集合（collections），和为这些业务模型创建了交互视图（views），完成了最基本的前端应用的功能——业务数据的展示。这是我们上次的终点。
光有数据的展示是不完整的，我们需要在界面上修改模型的数据，并且能看模型数据更新。在本文中，我们将介绍如何为程序添加控制器逻辑（controller-type logic），实现对模型的操控。
本文略译自《Backbone.js Basics: Models, Views, Collections and Templates》。
在上一篇教程里，我们展示了Backbone的Model组件的基本使用方法，使用了一个例子——冲浪板数据——展示如何用Model组件「结构化」业务数据，并且了为测试和完整，手动渲染出模型的数据。本文接着展示如何将「手动渲染UI的任务」结构化为V组件——使用Backbone的View组件API。
本文略译自《Backbone.js Basics: Models, Views, Collections and Templates》
在本教程中, 我们将探讨流行的 MV * 框架 Backbone 的基本原理。我们将介绍Backbone的主要几个API类：业务模型（models）、交互视图（views）、模型实例集合（collections）和视图模板（templates）, 并了解在构建应用程序时, 它们（模型、视图、集合和模板）是如何相互协作的。我们还会上升一级，讨论MVC框架的思想：MVC构件责任和关注点的分离，这是很基础的，能为我们构建具有构架合理的代码库，和可扩展（scalable）应用程序铺平道路。