我实际上正在我们项目的架构过程中。我们选择了 Mate 框架。该项目并没有那么复杂，但是当我选择模块时，我会比 MXML 获得什么优势。
Main App - > Views - > Events - > Maps - > Services [PHP or Java]
当我提出基于模块的架构时，它似乎很好，但我怀疑它不应该以紧密耦合和不需要的问题结束，这些问题可能会在以后解决。
Main APP - > Modules - > Module Interface -> Events - > Maps - > Services
[PHP or Java]
【问题讨论】：
标签： apache-flex
我已经使用 Mate 框架构建了多个 Flex 应用程序，但我的环境可能与您的环境有些不同。无论如何，回答您的问题：
如果我选择模块而不是 MXML 组件，我会得到什么好处？
模块应该用于您希望在多个应用程序中重复使用的功能。 KensoDev 提到的使用模块的好处是它们可以在其他应用程序中使用，而无需重写或复制代码。如果您正在构建的应用程序将是独立的，并且没有任何功能将被重用，我会直接使用 MXML。
构建 Flex 应用程序的首选和最佳方式是什么？
这确实取决于应用程序。我使用 Mate 构建的大多数应用程序都是基于 MXML 的，我们没有使用任何模块，但在您的情况下使用模块可能是有意义的。这完全取决于项目的要求。
既然应用程序要与后端通信，我们是否需要让前端更复杂？
我坚信让 UI 尽可能简单，并在中间层或后端完成所有繁重的工作。任何项目的目标都是让用户的生活更轻松或更方便。换句话说，呈现给用户的前端不应该很复杂，但底层业务逻辑和后端工作可能很复杂。
是否有任何基于模块的架构用于示例预览或他们定义了良好架构的任何示例。
Mate 有一些sample projects available for you to look 在他们如何构建他们的项目方面。如果有帮助，我们通常会像这样构建我们的项目：
src
|
|_assets (Images or other assets go here.)
|
|_ApplicationName
|
|_events (Your custom Mate events go here.)
|
|_maps (Your Mate Maps go here.)
|
|_model
| |
| |_managers (Your Data Managers go here. Most of the data processing from the back end happens here.)
| |
| |_vo (Your Value Object classes go here.)
|
|_ui
|
|_components (MXML components go here. Typically these are your "Front End" components.)
|
|_presenters (Your Presentation Models go here. Think of them as the "code behind" classes for your front end components.)
|
|_renderers (Any custom item renderers for lists of data grids go here.)
|
|_skins (Any custom skins for your components go here.)
|
|_views (Your application Views go here.)
我希望这会有所帮助！
【讨论】：
模块：使用模块的优点是应用程序的重量，拥有模块将使您的应用程序更精简，并且当您打开页面/选项卡时，您会将模块加载到应用程序中
模块的另一个优点是 DRY，您可以在多个应用程序中拥有模块，而无需编写两次代码或类似的任何东西。
Bet Way：这实际上是您的应用程序问题，对此没有绝对的真理。 我有没有任何模块的大型应用程序和其他更轻更简单的模块，每个应用程序都是特定的
复杂的客户端：如果你有后端，后端将是应用程序的服务层，你必须创建模型、视图、控制器/命令（可能）。
这是当今创建弹性应用程序的最佳方式（恕我直言）。
模块示例： Google for potomac，我想你会在那里找到你要找的东西 http://www.potomacframework.org/
【讨论】：
如果我选择模块而不是 MXML 组件，我会得到什么好处？
模块和组件是两个非常不同的东西。模块就像 Windows 中的 DLL 或 Java 中的 Jar 文件。因为它带有一段可以在运行时加载和卸载的代码。因此模块可以包含一个或多个 MXML 组件。它们不会取代 MXML 组件的使用。无论您是否使用模块，您仍将使用 MXML 构建您的应用程序。不幸的是，模块包含许多其他“功能”，这些“功能”并不像 Java 中的 Jar 文件那样简单。
它们有好处也有坏处。您可以通过加载和卸载代码来减少内存占用，但现在字节码大小并不是内存膨胀的主要原因。这实际上是语句如何使用导致内存上升的堆。您可以使用 SWC 在没有模块的情况下轻松地在项目之间共享代码，或者仅通过共享的 SVN 项目简单地共享代码。
模块的其他缺点是它会在您的程序中创建更多边界。从模块中引用对象可能是个问题。使用模块的对象可以引用模块中定义的对象，但反之则不行，因此如果您在组织模块时不小心，最终可能会将代码转储到不属于该模块的模块中。
如果我有明确的需求，我会开始不使用模块然后重构。一旦你开始使用模块，它们只会增加开发开销。
构建 Flex 应用程序的首选和最佳方式是什么？
MVC 或 MVCS。模型视图控制器或模型视图控制器服务。有些人觉得命令比控制器好，但实际上命令是只有一个控制器方法的控制器。这是一个退化的控制器。我喜欢控制器，因为它很容易通过添加一个方法而不是像命令指示的全新类来向控制器添加一个新命令。再加上一个控制器，您可以将屏幕、子系统等的常用功能组合在一起。您可以选择您想要的控制器的粒度。当控制器变得太大时，控制器也很容易被拆分。
MVCS 在没有框架的情况下很容易实现，但是使用框架是一个好主意，因为它可以帮助您的团队了解应用程序是如何组合在一起的。此外，开源软件在为您记录框架方面做得非常好，因此您不必回答很多关于框架的低级问题。好的选择是 Swiz、Parsley 或 Mate。然而，现在大多数人正在远离 Mate 和 Caringorm 转向 Swiz 或 Parsley。 Caringorm 将在未来成为 Parsley，仅供参考。
当您想要进行更多单元测试时，演示模型模式将为您提供帮助，因此了解其工作原理将对您的研究有益。虽然我更多的是对控制器和模型进行单元测试，并为视图或集成测试进行传统的 QA。质量检查要容易得多。
既然应用程序要与后端通信，我们是否需要让前端更复杂？
您必须决定希望前端处理多少复杂性。后台处理是 Flex 的一个弱点，因此有时将其传递给后端是有意义的。我想你会对前端的工作量感到惊讶。 Flex 是一种 RIA，这意味着更多的工作将发生在前端，这是正常的，但您必须决定在哪里做有意义的事情。
我的建议是前端使用 JSON 或 AMF (Blaze DS) 在后端调用简单服务。如果您需要服务器推送之类的东西，您可以使用 ActiveMQ，因为它具有与 Flex 的连接器。
是否有任何基于模块的架构用于示例预览或他们定义了良好架构的任何示例。
模块和架构是相互影响的，但是使用模块并不意味着你有一个定义明确的架构。您只需在其中转储代码的存储桶。模块不会在您的代码中指定职责或组织，这正是架构所做的。正如我所说的，模块就像 DLL，你看不到基于 DLL 的架构，你可以从现成的架子上拿起。像 Swiz 这样的框架将比模块更有助于定义您的架构。我想说的是不要再关注模块了，看看架构然后看看你是否需要它们。
【讨论】：