Question

我在大部分项目中使用骨干，我想我确切知道M V C的含义：M代表数据的抽象，V代表表示，C代表处理程序。

然而，在我目前的项目中，我发现有很多视图互相交互，而模式很少（服务器的数据）。

例如，我有一个名为V1 V2 V3的复杂视图，当用户在V1中执行某些操作时，V2应该做出相应的响应，V3等也会响应，并且在最后一步，可能需要请求数据从服务器。大部分请求都用于获取数据而不是修改数据。

它不喜欢常见的样式：一个模型的一个（或多个）视图，例如CRUD操作。

现在我有两个想法：

1虚拟模型

创建骨干模型以表示整个应用程序的状态，将此模型绑定到所有视图。听起来像将应用程序作为状态机。

虽然用不同的状态描述应用程序并不容易。

2使用事件调解员

使用事件调解器注册/取消注册不同的事件，然后视图可以触发或响应不同的事件。

虽然如何定义事件以避免不足或过度，一句话使事件正交并不容易。或者我还没有找到任何指示。

还有其他替代解决方案吗？

Answer 1

我认为这实际上是一个非常相关的问题。

创建骨干模型以表示整体状态应用程序，将此模型绑定到所有视图。听起来很像应用程序作为状态机。

如果模型不是与特定后端资源相对应的一致表示，那么这似乎不是一个好主意。
理想情况下，视图是单个模型或集合的表示。当一个视图被绑定到一个具有不相关属性的模型时，这在任何情况下都无法管理，这也是由于未来不可预见。

使用事件介体注册/取消注册不同的事件，然后视图可以触发或响应不同的事件。

我不认为让观点回应自定义事件总体上是一个好主意，但这对我来说是个人的。当应用程序变得更大时，为复杂的视图分配过多的责任可能会变得一团糟;因此，我将其作为一般规则来限制视图的任务：

渲染模板;
激活插件（如果它们特定于视图）;
DOM事件绑定;
（模型绑定）;
视图内部的方法（与DOM相关）;
触发自定义事件，以便在与视图交互后需要进一步操作时通知其他侦听器;

在任何情况下，根据我的经验，我发现使用自定义演示者/控制器来实例化/更新自定义事件的视图是实际的，而不是让视图本身担心这些事情。它让它们保持清洁，你总能知道你会在那里找到什么。

您提及的视图1,2和3可以从演示者重新呈现演示者做了类似的事情：

＆＃34;我从服务中获取一些数据并将其提供给我需要的一些视图他们。如果有什么变化，我会让他们知道＆＃34;

我通常每个相关的一组视图都有一个演示者。

我喜欢这种方法，因为：

它保持相关视图的逻辑集中;
当触发事件时，演示者只需要听一次它控制的所有视图;
主持人有权相互交谈，这比我所有观点开始互相交谈时更容易控制;

在简单的情况下，所有这些可能并不重要。但是在构建更大的应用程序时，我发现它可能变得一团糟。

我的两分钱

Answer 2

我有一个名为V1 V2 V3的复杂视图，当用户在V1中执行某些操作时，V2应该做出相应的响应，V3等也是如此

您似乎没有3个视图，但事实上1个视图有3个相互关联的部分。我会使用一个渲染3个子视图的超级视图，并监听视图事件。例如：

Backbone.View.extend({
  initialize: function () {
    this.v1 = ...;
    this.v2 = ...;
    this.v3 = ...;

    this.v1.on('user do something', this.v2.respondAccordingly);
    this.v1.on('user do something', this.v3.soDoesEtc);
  }
})

在视图1中：

$('button').on('click', function () {
  self.trigger('user do something');
})

Answer 3

这是许多Backbone开发人员面临的问题。

我过去所做的就是拥有一个baseModel / baseCollection，并将它们视为一个抽象的类/接口，尊重其他模型/集合。这些基础对象将包含一个侦听器/触发器方法，然后我可以在我的应用程序中使用这些方法，使一个模型/集合中的更改能够分别按照我的选择启动集合/模型的更新（从而触发视图更改）。使用这种方法允许我通过让适当的对象按照我的意愿适当地监听/广播事件来编写我的应用程序。

我的一个朋友创建了一个服务器端JS状态机，它可以启动超级模型（应用程序级模型反过来可以触发子视图模型/集合更新）。

当然，Marionette提供了一个框架，可以减少手动操作，让您重新编写应用程序代码。

Backbone.js的一个乐趣和负担是你拥有所需的所有灵活性。：）

使用具有多个视图和小模型的主干

3 个答案: