PureMVC (AS3) 中的继承类和动态视图
我想知道在这种情况下 PureMVC 中继承类的视图的最佳实践：
- 多个类继承一个 BaseClass（比方说 InheritedClass1 和 InheritedClass2）
- 每个 InheritedClass 都有一个各自的视图（从基视图类派生，但每个视图都是唯一的）
- 对于给定的数据集（假设 InheritedClass1/2 对象的 ArrayCollection），需要动态加载相应的视图。
- 数据集相对较大，所以 TileList 会很好（因为它只实例化当前显示的对象）
我可以想到几个解决方案，但我发现它们太“hackish”，不能成为最佳解决方案：
在视图中：BaseClassView 上的中继器，将视图属性赋予状态（设置为“InheritedClass1”状态以添加 InheritedClass1 对象） 优点：不会增加不必要的内存（状态对象在需要时实例化） 缺点：视图依赖于数据类型，因此增加了耦合
在中介器中：循环遍历 ArrayCollection 并 addChild() 基于数据类型的视图 优点：有效。 缺点：Mediator 正在向 View 添加东西，这就违背了 Mediator 和 View 分离的初衷。 比 Repeater 慢。
任何意见或其他建议将不胜感激。 谢谢！
I was wondering best practices for views of inherited classes in PureMVC in this situation:
- Multiple classes inherit a BaseClass (lets say InheritedClass1 and InheritedClass2)
- Each InheritedClass has a respective view (derived from a base view class, but each unique)
- With a given dataset (lets say ArrayCollection of InheritedClass1/2 Objects), the respective views need to be dynamically loaded.
- The dataset is relatively large, so a TileList would be nice (since it only instantiates objects which are currently displayed)
I can think of a couple solutions, but I find them to be too "hackish" to be the best solution:
In View: Repeater over a BaseClassView which attributes a view to a State (set to the "InheritedClass1" state to add a InheritedClass1 object)
Pros: No unneeded memory increase (States' objects are instantiated when needed)
Cons: View is dependent on the data types, so adds couplingIn Mediator: Loop over the ArrayCollection and addChild() the views based on data type
Pros: Works.
Cons: Mediator is adding things to the View, which defeats the point of the separation of Mediator and View. Slower than a Repeater.
Any comments or other suggestions would be appreciated. Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
如果您喜欢第一个示例，答案很简单。 为什么不在中介器上有一个映射（Object()）来为视图组件（或状态）分配数据类型。 例如：
中介者可以将该映射分配给 BaseClassView。
我可能同意这样的想法，即您需要某种形式的 viewProxy 来根据从中介提供给它的数据来呈现所有继承的视图（例如，第一个示例）。 尽管没有更具体的示例，但可以确认或否认状态是否是 UI 中的最佳操作方案。
The answer is simple if you like the first example. Why not have a map (Object()) on the mediator that assigns datatype to view component (or states). e.g.:
And the mediator can assign that map to the BaseClassView.
I'm likely to agree with the idea that you need some form of viewProxy that renders all your inherited views based on data fed to it from the mediator (e.g., first example). Can confirm or deny whether states is the best course of action in your UI though without more concrete examples.
中介者是视图的一部分。 我无法理解如何将它们与视图分开。
我选择了选项 2。
这是来自 pureMVC 论坛的主题：动态添加视图组件: 我应该在哪里做？。
您应该对“pureMVC”的帖子感兴趣。
此外，数据集的大小也可能存在问题。 如果它真的很大，您应该考虑使用带有渲染器的列表，而不是为每个项目添加一个组件（重复器就是这样做的）。 这会使事情变得更加复杂，因为您必须包装数据以保持主要组件与模型的解耦。
Mediators are part of the View. How would you separate them from the View is beyond me.
I'd got with option 2.
Here's a topic from the pureMVC forum: Dynamically adding View components: where should I do it?.
The post by "pureMVC" should be of interest to you.
Also, the size of the dataset can be problematic. If it's really large you should consider using a List with renderers instead of adding a component for each item (repeaters do that). Which would further complicate things a bit because you'll have to wrap your data to keep the main component decoupled of the Model.
，视图组件除了显示域数据并可能允许用户与其交互之外没有其他目的。 假设视图组件需要对域数据有一定的了解。
因此，将 VO 集合提供给视图组件不会增加“不良”耦合。 “坏”耦合是指视图组件知道如何进入模型层并操作保存数据的代理。 或者当模型层中的代理知道如何获取视图组件或中介者以将数据插入其中时。
正如 Coded Signal 所指出的，我们并不是试图将 Mediator 与 View 组件分开。 中介者是 PureMVC 系统中的一个参与者，它应该了解视图组件，并协调视图组件与系统其余部分之间的通信。 在松开视图层和模型层之间的耦合方面，中介者是系统中最关键的参与者。
为了与视图组件进行通信，其他参与者会发送通知，中介者会通过操作视图组件公开的 API 来听到并响应这些通知； 向其提供数据或调用其方法。 这有效地使应用程序的其余部分不需要了解有关该组件的任何信息。
中介器还侦听组件的事件并代表其执行操作，从模型层检索数据，或向其他中介器发送注释或触发控制器层中的命令。 这使得组件不必了解有关其所连接的系统的任何信息。 它只是公开一个属性和方法的 API，封装自己的行为，并在系统应该知道的事情发生时发送事件。
因此，中介器和视图组件一起构成了应用程序的视图层。
-=悬崖>
Typically, a view component has no other purpose than to display the domain data and possibly allow the user to interact with it. It is a given that the view component will need to have some understanding of the domain data.
So feeding a collection of VOs to your view component doesn't add a 'bad' coupling. A 'bad' coupling is when the view component knows about how to reach into the Model tier and manipulate the Proxy that holds the data. Or when the Proxies in the Model tier know how to get their hands on the view components or their Mediators to poke data into them.
As Coded Signal pointed out, we're not trying to separate the Mediator from the View component. The Mediator is the one actor in the PureMVC system that should know the view component, and mediate the communications between it and the rest of the system. The Mediator is the most critical actor in the system with regard to loosening the coupling between the View tier and the Model tier.
To communicate with the view component, other actors send notifications, which the Mediator hears and responds to by manipulating the view component's exposed API; spoonfeeding it data or invoking methods on it. This effectively keeps the rest of the app from needing to know anything about the component.
The Mediator also listens to the component for events and acts on its behalf, retrieving data from the Model tier, or sending notes to to other Mediators or to trigger Commands in the Controller tier. This keeps the component from having to know anything about the system it is connected to. It simply exposes an API of properties and methods, encapsulates its own behavior and sends events when things happen that the system should know about.
So together, the Mediators and View components make up the View Tier of the application.
-=Cliff>
实际上并非如此：它们是文档中所指的协作对，并且应该被视为协作对。
Not really: they're what the documentation refers to as a collaboration pair and should be treated as such.