0

我想知道在这种情况下 PureMVC 中继承类视图的最佳实践：

  • 多个类继承一个 BaseClass（比如说 InheritedClass1 和 InheritedClass2）
  • 每个 InheritedClass 都有各自的视图（派生自基本视图类，但每个都是唯一的）
  • 对于给定的数据集（假设是 InheritedClass1/2 对象的 ArrayCollection），需要动态加载相应的视图。
  • 数据集相对较大，所以 TileList 会很好（因为它只实例化当前显示的对象）

我可以想到几个解决方案，但我发现它们太“hackish”而不能成为最佳解决方案：

  • 在视图中：在 BaseClassView 上的中继器将视图属性分配给状态（设置为“InheritedClass1”状态以添加 InheritedClass1 对象）优点：没有不必要的内存增加（状态的对象在需要时被实例化）缺点：视图取决于数据类型，因此增加了耦合

  • 在 Mediator 中：循环 ArrayCollection 和 addChild() 基于数据类型的视图 Pros: Works。缺点：Mediator 正在向 View 添加东西，这违背了 Mediator 和 View 分离的观点。比中继器慢。

任何意见或其他建议将不胜感激。谢谢！

4

4 回答 4

1

中介是视图的一部分。你如何将它们与视图分开是我无法理解的。

我选择了选项 2。

这是 pureMVC 论坛的一个主题：动态添加视图组件：我应该在哪里做？. 您应该对“pureMVC”的帖子感兴趣。

此外，数据集的大小可能存在问题。如果它真的很大，您应该考虑使用带有渲染器的列表，而不是为每个项目添加一个组件（中继器这样做）。这会使事情变得更加复杂，因为您必须包装数据以使主要组件与模型分离。

于 2009-07-14T11:19:55.833 回答
1

如果您喜欢第一个示例，答案很简单。为什么不在将数据类型分配给视图组件（或状态）的中介上使用映射（Object（））。例如：

private static var map:Object = {"ic_oneType": "ic_oneState",
                                 "ic_twoType": "ic_twoState"}

中介可以将该映射分配给 BaseClassView。

我可能同意您需要某种形式的 viewProxy 的想法，该视图代理根据从中介提供给它的数据呈现所有继承的视图（例如，第一个示例）。尽管没有更具体的示例，但可以确认或否认状态是否是 UI 中的最佳操作过程。

于 2009-07-14T11:15:50.197 回答
1

缺点：视图依赖于数据类型，因此增加了耦合

通常，视图组件除了显示域数据并可能允许用户与之交互之外没有其他用途。视图组件需要对领域数据有一定的了解，这是给定的。

因此，将一组 VO 提供给您的视图组件不会添加“坏”耦合。一个“坏”的耦合是当视图组件知道如何进入模型层并操作保存数据的代理时。或者当模型层中的代理知道如何获得视图组件或它们的中介以将数据插入其中时。

Mediator 是在向 View 中添加东西，这违背了 Mediator 和 View 分离的观点。

正如 Coded Signal 指出的那样，我们并没有试图将 Mediator 与 View 组件分开。Mediator 是 PureMVC 系统中的一个参与者，它应该知道视图组件，并调解它与系统其余部分之间的通信。中介者是系统中关于放松视图层和模型层之间的耦合的最关键的参与者。

为了与视图组件通信，其他参与者发送通知，中介者通过操作视图组件的公开 API 来听到和响应；用勺子喂它数据或调用它的方法。这有效地使应用程序的其余部分无需了解有关该组件的任何信息。

中介者还监听组件的事件并代表它采取行动，从模型层检索数据，或向其他中介者发送注释或触发控制器层中的命令。这使组件不必知道它所连接的系统的任何信息。它只是公开一个属性和方法的 API，封装自己的行为，并在系统应该知道的事情发生时发送事件。

因此，中介者和视图组件一起构成了应用程序的视图层。

-=悬崖>

于 2009-12-07T23:39:06.950 回答
0

缺点：Mediator 是在向 View 添加东西，这违背了 Mediator 和 View 分离的观点

不是真的：它们是文档所指的协作对，应该这样对待。

于 2009-07-30T18:21:03.440 回答