Question

我实际上正处于项目建筑的过程中。我们选择了Mate框架。该项目并不是那么复杂，但是当我选择模块时，我将获得MXML的优势。

Main App - > Views - > Events - > Maps - > Services [PHP or Java]

当我提出基于模块的体系结构时，它似乎很好，但我怀疑它不应该以紧密耦合和不必要的问题结束，这些问题可能会在以后解决问题。

Main APP - > Modules - > Module Interface -> Events - > Maps - > Services 
[PHP or Java]

如果我选择，我会得到什么好处 MXML Component上的模块？
什么是首选和最好的构建Flex的方法应用
自应用程序发布以来与Backend沟通，我们需要吗？使前端更复杂？
是否有基于模块的用于样本预览的结构或任何他们定义了良好架构的例子。

Answer 1

模块：使用模块的优势在于应用程序的重量，拥有模块可以让您获得更精简的应用程序，当您打开页面/选项卡时，您可以将模块加载到应用程序中

模块的另一个优点是DRY，你可以在几个应用程序中拥有模块而无需编写代码两次或类似的东西。

投注方式：这真的是你的申请问题，没有绝对的事实。我有没有任何模块的大型应用程序，其他更轻，更简单的模块，它是真正具体的每个应用程序

复杂的客户端：如果你有一个后端，后端将是应用程序的服务层，你将不得不创建一个模型，视图，控制器/命令（可能）。

这是现在创建Flex应用程序的最佳方式（恕我直言）。

模块示例：谷歌为波托马克，我想你会发现你在那里寻找什么 http://www.potomacframework.org/

Answer 2

我使用Mate框架构建了几个Flex应用程序，但我的环境可能与您的环境有所不同。无论如何，要回答你的问题：

如果我选择模块而不是MXML组件，我会得到什么好处？

模块应该用于您希望在多个应用程序中重用的功能。使用KensoDev提到的模块的好处是它们可以在其他应用程序中使用，而无需重写或复制代码。如果您正在构建的应用程序将是独立的，并且没有任何功能可以重复使用，那么我将使用直接MXML。

构建Flex应用程序的首选和最佳方法是什么？

这确实取决于应用程序。我使用Mate构建的大多数应用程序都是基于MXML的，我们没有使用任何模块，但在您的案例中使用模块可能是有意义的。这完全取决于项目要求。

由于应用程序将与Backend进行通信，我们是否需要使前端更复杂？

我坚信使用户界面尽可能简单，并在中间层或后端完成所有繁重的工作。任何项目的目标都是让用户的生活更轻松或更方便。换句话说，呈现给用户的前端不应该是复杂的，但底层的业务逻辑和后端工作可能是。

是否有任何基于模块的Archiecture用于示例预览或任何已定义良好架构的示例。

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.)

我希望这有帮助！

Answer 3

如果我选择模块而不是MXML组件，我会得到什么好处？

模块和组件是两个截然不同的东西。模块类似于Windows中的DLL或Java中的Jar文件。因为它带有一段可以在运行时加载和卸载的代码。因此，模块可以包含一个或多个MXML组件。它们不会取代MXML组件的使用。无论是否使用模块，您仍将使用MXML构建应用程序。不幸的是，模块中包含许多其他“功能”，这些功能并不像Java中的Jar文件那样简单。

他们有上行和下行空间。您可以通过加载和卸载代码来减少内存占用，但是现在字节代码大小并不是内存膨胀的主要原因。实际上，语句如何使用导致内存上升的堆。您可以使用SWC轻松地在没有模块的项目之间共享代码，也可以通过共享的SVN项目轻松共享代码。

模块的其他缺点是它会在程序中创建更多边界。从模块内引用对象可能是个问题。使用模块的对象可以引用模块中定义的对象，但反之亦然，因此如果您不小心组织模块，最终可能会将代码转储到不属于该模块的模块中。

如果我明确需要它，我会开始不使用模块然后重构。一旦你开始使用模块，模块只会增加开发开销的开销。

构建Flex应用程序的首选和最佳方法是什么？

MVC或MVCS。模型视图控制器或模型视图控制器服务。有些人被挂断了命令优于Controller，但实际上Command是一个只有一个控制器方法的Controller。这是一个退化的控制器。我喜欢控制器，因为通过添加一个方法而不是像Commands指令那样添加一个新类，很容易向Controller添加一个新命令。另外，控制器允许您将通用功能组合在一起用于屏幕，子系统等。您可以选择您希望控制器的细粒度。控制器也可以在太大时轻松拆分。

没有框架，MVCS很容易做到，但使用框架是一个好主意，因为它可以帮助您的团队了解应用程序的组合方式。此外，开源软件可以很好地为您记录框架，因此您无需回答有关框架的大量低级问题。很好的选择是Swiz，Parsley或Mate。然而，大多数人现在正在转移到Swiz或Parsley，远离Mate和Caringorm。 Caringorm将在未来的FYI中成为Parsley。

演示模型模式将帮助您进行更多单元测试，以便了解其工作原理对您的研究是否有益。虽然我更像是一个单元测试控制器和模型，并为View或集成测试做传统的QA。质量保证更容易。

由于应用程序将与Backend进行通信，我们是否需要使前端更复杂？

您必须决定前端需要处理多少复杂程度。后台处理是Flex的一个弱点，所以有时候传递到后端是有意义的。我想你会对前端的工作量感到惊讶。 Flex是一个RIA，这意味着前端会有更多的工作正常进行，但你必须决定做什么才有意义。

我的建议是前端使用JSON或AMF（Blaze DS）调用后端的简单服务。如果你需要像服务器推送这样的东西，你可以使用ActiveMQ，因为它有Flex的连接器。

是否有基于模块的架构用于示例预览或任何已定义良好架构的示例。

模块和体系结构相互影响，但使用模块并不意味着您拥有定义良好的体系结构。您只需要将代码转储到存储桶中。模块不会在代码中指定职责或组织，而这正是架构所做的。正如我所说的模块就像DLL，你没有看到基于DLL的架构，你可以从现成的架子上取货。像Swiz这样的框架将比模块更有助于定义您的架构。我会说停止关注模块并查看架构然后看看你是否需要它们。

MXML组件架构上的Flex模块

3 个答案: