FlashBuilder 松耦合且可重用的组件架构
我希望我的 mxml 或 actionscript 组件可重用且松散耦合。我想知道使用 FlexGlobals.topApplication 来调度和侦听事件是否是一个好习惯。例如，我希望我的登录组件将事件分派到 topApplication，因此当我在不同的项目中重用该组件时，我不必更改任何内容，因为所有应用程序都有一个 topApplication。
我的另一个选择是使用一个单独的静态类来处理事件分派，但随后我创建对该静态类的依赖项。 任何建议将不胜感激。 谢谢。
I want my mxml or actionscript components to be reusable and loosly coupled. I am wondering if it is good practice to use the FlexGlobals.topApplication to dispatch and listen for events. For instance I want my login component to dispatch events to the topApplication so when i reuse that component in a different project I won't have to change anything being all applications have a topApplication.
My other option is to have a separate static class to handle event dispatching but then I am creating a dependency on that static class.
Any suggestions would be appreciated.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我建议您阅读有关事件传播的内容，并让您的登录组件将事件分派给捕获该事件的“任何人”，因为该事件在层次结构中向上冒泡。
http://livedocs.adobe.com/flex/3 /html/help.html?content=events_08.html
I would recommend that you read about event propagation and have your login component dispatch the event to "whoever" catches it as it bubbles up through the hierarchy.
http://livedocs.adobe.com/flex/3/html/help.html?content=events_08.html
我在很大程度上同意斯蒂安在这里的回答。关于weltraumpirat的评论，我觉得依赖注入可能很棒，但在IMO上也增加了很多调试/测试的复杂性，如果你实际上不打算有一个接口的不同实现，那么只会添加很多垃圾代码来查看却没有任何实际的好处。我觉得 Spring 在服务层方面效果很好，因为如果您切换数据库或类似的东西，您可以更改数据访问层 (DAO) 的实现，但我很难看到前端的好处。
我不建议使用 topLevelApplication 因为你最终会得到像 cairngorm 这样的东西，在顶层你有一组巨大的事件/事件处理程序。更不用说如果你遵循他们建议的模型，你最终会得到一堆毫无意义的事件类，这些事件类只是简单地定义一个字符串（使用 Cairngorm 有更好和更糟糕的方法来实现它，但我不喜欢我在野生）。
我公司的一位开发人员编写了一个自定义的 MVC“微框架”，它对我们来说非常有用，我们可以将控制器附加到任何显示对象来为其处理事件，这非常有效，但确实需要开发/测试它的初始开销。它构建在 Flex 中现有的事件方案之上，因此我们的 MVCEvent 类扩展了 Event（默认情况下我们只是冒泡，因为我们倾向于希望它用于我们正在创建的事件类型，其中控制器可以位于 UIComponent 调度之上的任何级别）事件，并且始终可以选择关闭冒泡，但是从 Event 基类开始意味着我们可以利用内置的 EventDispatcherdispatchEvent() 方法）。他编写了几乎所有内容，使用接口来定义每个部分的方法，并且仅假设对象实现了要在特定上下文（如 IMVCEvent、IMVCCommand 中）中使用的给定接口，如果内置框架实现不适用于根据您的特定场景，您只需要创建一个实现相同接口的新类（如果扩展也不适用于您的情况）。这提供了巨大的灵活性，但同时我们通常能够重用事件、命令或控制器的现有实现。在每个应用程序中，我们只是为特定于应用程序业务规则的事物定义新的视图和命令。
那么这一切归结为什么呢？我建议您将自己的库作为一个库，然后在您的许多项目中重复使用该库。您将彻底了解自己的库，并可以根据需要快速调整它，而无需尝试了解某人设计 MVC 框架来处理的许多用例。
我意识到，就现在完成某件事的速度而言，这不是一个理想的解决方案，但我认为从长远来看，这确实是最好的解决方案（这对我们来说非常好，这就是我能说的全部）。
此处的修改是为了承认现有的 Flex MVC 框架可用并安抚群众。
机器人腿
顺便看看机器人腿的创建者对于使用他的代码有什么看法：他的话不是我的
瑞士
伴侣
关于 Flex 框架的 Stackoverflow 问题
I have to agree with the answer by Stian here for the most part. With regard to weltraumpirat's comment I feel dependency injection can be great but also adds a lot of complication with regard to debugging/testing IMO and if you're not actually going to have different implementations of an interface just adds a lot of garbage code to look through without any real benefit. I feel like Spring on the service layer side works out well because you can change out implementations for the data access layer (DAO) if you switch DBs or something of that nature but it's hard for me to see the benefit on the front-end.
I would not recommend using the topLevelApplication as you'll end up with something like cairngorm where you have this humongous set of events/event handlers happening at the top level. Not to mention if you follow their suggested model you end up with a bunch of pointless event classes that simply define a string (there's better and worse ways to go about it using Cairngorm but I'm not a fan of what I've seen in the wild).
A developer at my company wrote a custom MVC "micro-framework" that works great for us where we can attach a controller to any display object to handle events for it, this works wonderfully but does require the initial overhead of developing/testing it. It's built on top of the existing Event scheme in Flex so our MVCEvent class extends Event (ours just bubble by default as we tend to want this for the types of events we're creating where the controller could be at any level above the UIComponent dispatching the event, and can always opt to turn off bubbling, however starting with the Event base class means we can utilitze the built in EventDispatcher dispatchEvent() method). He wrote just about everything using an interface to define the methods for each part and only assuming objects implement a given interface to be used in a particular context (as in IMVCEvent, IMVCCommand) this way if the built in framework implementation doesn't work for your particular scenario you just need to create a new class that implements the same interface (if extension also doesn't work for your case). This gives a huge amount of flexibility yet at the same time we're generally able to just re-use existing implementations of events, commands, or controllers. In each app we're just defining new views and commands for things that are specific to the business rules of the application.
So what's that all boil down to, I suggest you roll your own as a library then re-use that library for your many projects. You will know your own library in and out and can tweak it as you see fit quickly without trying to understand the many use cases someone designed their MVC framework to handle.
I realize this isn't an ideal solution in terms of speed to get something done now, but I think it really is the best solution for the long haul (it's been great for us that's really all I can say).
Amendment here to acknowledge the existing Flex MVC frameworks available and appease the crowd.
Robot Legs
By the way see what the creator of robot legs has to say about using his code: His words not mine
Swiz
Mate
Stackoverflow question about flex frameworks