在我的大多数项目中,我都使用主干,我想我非常清楚my的含义:M表示数据的抽象,V表示表示,C表示处理程序。
然而,在我当前的项目中,我发现有很多视图是相互交互的,而很少有模式(与服务器的数据)。
例如,我有一个名为V1 V2 V3的复杂视图,当用户在V1中做一些事情时,V2应该相应地做出响应,V3等也应该响应,在最后一步,可能会发出请求从服务器请求数据的命令。大多数请求用于获取数据,而不是修改数据。
它不喜欢普通的样式:一个模型的一个(或多个)视图,比如CRUD操作。
现在我有两个想法:
1虚拟模型
创建一个主干模型来表示整个应用程序的状态,将该模型绑定到所有视图。听起来像使应用程序成为状态机。
然而,用不同的状态来描述应用程序并不容易。
2使用事件中介
使用事件中介注册/取消注册不同的事件,然后视图可以触发或响应不同的事件。
而如何定义事件以避免不足或过大,总之使事件正交是不容易的。或者我还没找到任何指示。
还有其他替代的解决办法吗?
发布于 2015-07-02 03:28:25
我认为这其实是一个相当相关的问题。
创建一个主干模型来表示整个应用程序的状态,将该模型绑定到所有视图。听起来像使应用程序成为状态机。
如果模型不是与特定后端资源相对应的一致表示,那么这似乎不是一个非常好的主意。
理想情况下,视图是单个模型或集合的表示。当视图被绑定到具有不相关属性的模型时,这似乎不太实用,在所有情况下都是如此,这也是由于一个不可预知的未来。
使用事件中介注册/取消注册不同的事件,然后视图可以触发或响应不同的事件。
我不认为让视图响应自定义事件总体上是个好主意,但这是我个人的想法。当应用程序变得更大时,将过多的责任分配给复杂视图可能会变得一团糟;因此,我把将视图的任务限制在以下几个方面作为一般规则:
无论如何,在我的经验中,我发现使用自定义演示器/控制器实例化/更新自定义事件的视图是可行的,而不让视图本身担心这些事情。它使它们保持干净,你总是知道你会在那里找到什么。
您提到的视图1、2和3可以从演示者重新呈现。
推荐人所做的事情如下:
我从一项服务中获得一些数据,并将其提供给我的一些需要它们的视图。如果有什么变化,我会让他们知道的
我通常有一个主持人每组相关的意见。
我喜欢这种方法,因为:
在简单的情况下,所有这些可能并不重要。但是当构建一个更大的应用程序时,我发现它可能会变得一团糟。
我的两分钱
发布于 2015-07-07 23:11:41
我有一个名为V1 V2 V3的复杂视图,当用户在V1中做一些事情时,V2应该相应地做出响应,V3等等。
它似乎没有3个视图,但实际上有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');
})发布于 2015-07-07 22:48:47
这是许多骨干开发人员面临的问题。
我过去所做的就是拥有一个baseModel/baseCollection,并将它们作为抽象类/接口来处理,其他模型/集合从抽象类/接口扩展而来。这些基本对象将包含一个侦听器/触发器方法,然后我可以在整个应用程序中使用这些方法,使一个模型/集合中的更改能够根据我的选择分别启动集合/模型的更新(从而触发视图更改)。使用这种方法,我可以通过让适当的对象适当地侦听/广播事件来编写我的应用程序。
我的一个朋友创建了一个服务器端的JS状态机,它将启动超级模型(应用程序级模型,这反过来可以触发子视图模型/集合更新)。
当然,木偶提供了一个框架,可以减少一些手工操作,并允许您重新编写应用程序代码。
Backbone.js的乐趣和负担之一是,您拥有所需的所有灵活性。:)
https://stackoverflow.com/questions/30892469
复制相似问题