大型 Flex 应用程序的最佳实践？答案

【问题标题】：Best Practices for large Flex apps?大型 Flex 应用程序的最佳实践？
【发布时间】：2011-01-30 19:09:31
【问题描述】：

我正在创建一个相当大的 flex 应用程序，随着时间的推移，它开始趋向于不可维护。

我正在使用 3 个外部库项目，它们仍然足够小以保持可维护和可重用，但主项目似乎无法保持井井有条。

部分问题似乎是我有大约 30 个对象继承自一个抽象超类类型对象。所有的子对象都有一个逻辑组件和一个用户界面组件，它们彼此紧密集成。超类对象有大约 60 个共享方法和属性，其中大部分可以在任何子类中被覆盖，其中一些应该在所有子类中被覆盖。

为了增加复杂性，它们之间必须进行通信，这通常是通过它们所在的容器对象。此外，主项目必须从这些对象中创建值对象，以便将它们发送到 FlourineFX 后端用于存储，以及额外的身份验证/授权逻辑。

我已经用旧的 MS BASIC（前 VB）、Ada、VB（3 到 .Net 1）、C++ 和 C# 的语言创建了更大的项目，没有这个问题。（好吧，由于 UI 和逻辑之间的紧密集成，旧 VB 倾向于解决这个问题）那么，我是否缺少任何东西，或者有什么可以实现的最佳实践？（即使这意味着重写整个代码段）

是的，这可能是this 对话的扩展。

【问题讨论】：

标签： apache-flex actionscript

【解决方案1】：

您似乎只需要干净地分离 UI 和域组件。查看 Martin Fowler 讨论的 component guidelines 和 Presentation Patterns，尤其是 Presentation Model。

要将这些部分组合在一起，您可能需要使用像 Spring ActionScript 这样的 IoC 容器。这是一个非侵入式框架，可让您保持层分离。

不要让框架妨碍您。我看到了像 PureMVC 和 Cairngorm 这样的框架被大量滥用的情况，主要是因为以全有或全无的方式应用它们。

【讨论】：

【解决方案2】：

James Hay 的对话启动器是一个很好的启动器，但对于大型应用程序，我会花时间测试并考虑内存管理，以解决该答案/对话中的一些建议。 RobotLegs 很棒，但我会担心它会产生“过度单例化”和潜在的内存管理问题（尽管我不得不承认我从未使用过和避免使用 robotLegs，因为它使用了单例）。如果您正在考虑 IoC 和依赖注入（就像 robotsLegs 提供的那样），我建议您看看 swiz——我真的很喜欢新的“实例方向”swiz。我唯一的问题（在当前测试版中）是它们有一些清理问题，尽管这些问题很容易解决（查看它们的源代码，并且任何时候你从舞台上完全删除一个组件，你都必须播放分析游戏并确保所有内容都得到清理——我们必须创建临时函数来删除 changewatchers 并销毁“显示列表 bean 实例”，直到它们得到修复为止）。

我领导的项目有许多您必须担心的潜在问题。我们的 ERP 应用程序有数千个模块，并且每次在客户端计算机上运行数小时/数天，不断加载和卸载模块。垃圾收集和内存管理过去和现在都是问题。

至于使用 mate、烦人的车喇叭或 pureMVC，我们在两年前创建了自己的框架。它借鉴了 cairngorm 的想法，但总的来说，我的建议是在考虑垃圾收集的同时，使用你可以快速学习、理解和教授的任何东西。我们的内部模型和视图类现在使用 swiz（用于新开发的模块），这使得可维护性和代码可读性超级流畅。

我希望我的喋喋不休至少有所帮助。祝你好运。

【讨论】：

@jeremy.mooer - RobotLegs 实际上并不使用单例，因此“过度单例化”点实际上是不正确的。它实际上是非常可单元测试的，比 Pmvc 强得多。
@James Hay- 是的，就像我说的，从来没有用它来澄清。我可能应该在某个时候再次下载源代码。对于具有类 openFlux 或类 flex4 架构的模型/控制器，我绝对会使用普通的 ol' 类 + 在 Carhorn、pmvc 或 mate 上的 robotLegs。我一直很惊讶，一家主要的 flex 咨询公司总是使用 pureMVC 来进行基础合同。我想如果您的目标“用户使用时间”是一小时 LT.. 这可能很典型。无论如何，我宁愿支持不需要 10 多个文件来获得简单视图的东西。

【解决方案3】：

您在这个项目中使用任何框架实现吗？框架将有助于将这种复杂性模块化，并有望消除您在应用程序逻辑和视图之间似乎存在的许多依赖关系。

我是 RobotLegs 框架的大力倡导者，它实现了 mvcs 模式并提供依赖注入以供您在整个项目中使用。还有其他的，例如pureMvc、Cairngorm、Mate。环顾四周，看看哪个最适合您的项目。

在我看来，您确实需要进行大型重构，这在如此大的项目中是一个冒险的过程。如果您正在努力维护它，那可能是非常值得的。如果你要重构肯定重构为一个框架。这可能是让你物超所值的领域（英国人用英镑；））

【讨论】：

FWIW，我们在应用程序套件的某些部分使用 pureMVC，我相信它会增加很多不必要的复杂性和间接性。不使用框架的部分似乎更容易构建，更容易维护。这是一个大型 SaaS 套件，其中包含许多应用程序和模块。 YMMV。
我自己也不是 PureMvc 的忠实粉丝，但主要是因为它的可测试性。 RobotLegs 更容易进行单元测试。在有和没有框架的大型项目中工作过，我确实看到了使用它们的好处，特别是当它们将在未来得到维护时。我的部门现在从事的任何项目都订阅了某种框架，因此我们有一个标准实现，可以更轻松地从一个项目跳转到另一个项目。
我实际上并没有使用框架，在研究了这个之后，它可能是解决方案的一个很好的部分。谢谢