2011-07-17 14 views
3

来自Robotlegs/PureMVC,我非常熟悉视图介体的概念,即非常倾听来自“虚拟”视图的事件/请求并发出进一步请求,发送应用程序范围信号的组件/ event,根据视图的请求执行命令等。Flex4主机组件是否具有与视图介体/帮助程序相同的功能?

Flex 4中引入的主机组件思想可以被认为与中介相同吗?唯一让我略感困扰的是主机组件仍被视为视图,因为它们扩展了SkinnableComponent或任何进一步继承它的类。在我看来,调解员应该完全置身于视野逻辑之外。不过,我不想为该主机组件编写皮肤,主机组件和视图介体,因为这会带来相当大的开销,并且会导致更多的复杂性而不是抽象。

我应该使用主机组件作为中介,并在那里放置应用程序级别的逻辑,例如应用程序级别的事件分派?

回答

1

我也为SkinnableComponent模式感到困惑。我喜欢我的行为,生活在不是视图组件的类中。我甚至不喜欢引用视图组件,所以我倾向于选择“演示模型”模式。与SkinnableComponent,主机组件仍然是一个视图组件,但它包含所有的共享行为。这感觉有点混乱,我不是这个巨大的粉丝。不过,我确实认为这是构建可重用,可换肤组件的一种非常好的方法。例如,如果您是组件开发人员,那就太棒了。

这就是说,我觉得它太复杂了,没有皮肤,主机组件和分离的行为类。正因为如此,我倾向于坚持自己给予我们的模式(皮肤和主机组件)以获取可换肤组件。根据我的经验,它使测试变得更加复杂,但它就是这样。

如果我不需要SkinnableComponent(因为我通常不会创建用于外部消费的可换肤组件),我只需使用单独的表示模式(通常是PM)并放弃蒙皮模式。

+0

+1 from me;尽管我也质疑组件开发人员的“优秀”。扩展Spark体系结构仍然存在许多扩展MX体系结构的问题;除了现在事情在许多不同的类之间被抛出,并且很难弄清楚发生了什么。 – JeffryHouser

+0

@ www.Flextras.com:好点。我来自一个角度,我将它与Silverlight中的“模板化”进行了比较。我更喜欢皮肤类方法,因为它允许您从现有皮肤派生以更改单个属性(与在Silverlight中复制整个模板和更改一个属性相反)。面向对象的方法是我认为很好的。但我同意,Flex4中的“可换肤组件”模式仍然存在很多摩擦。 –

相关问题