多个RemoteObjects - 最佳实践

Question

我有一个大约20个模型和控制器的应用程序，并没有使用任何特定的框架。在Flex性能方面使用多个远程对象的最佳实践是什么？

1）方法1 - 每个组件一个 - 每个组件为自己实例化一个RemoteObject

2）方法2 - 应用程序根目录中的多个 - 每个控制器由根目录中的RemoteObject处理

3）方法3 - 应用程序根目录中的一个 - 将所有控制器合并为一个类并使用一个RemoteObject处理它们

我猜3会有最好的表现，但是维护得太乱，1会是最干净但会受到性能影响。你觉得怎么样？

Answer 1

最佳做法是“以上都不是”。您的视图应调度控制器或Command组件用于调用服务的事件，然后在返回数据时更新模型。您的视图将绑定到数据，然后视图将自动使用新数据进行更新。

我的偏好是每个不同的部分或我正在检索的数据类型都有一个服务类 - 这样可以更容易地构建模拟服务，根据您正在做的事情，可以根据需要交换实际服务（例如如果您有一个复杂的服务器设置，正在进行蒙皮的开发人员将使用模拟）。但实际上，你如何做到这一点只取决于个人偏好。

那么，您的服务在哪里，控制器或命令可以到达它们？如果使用依赖注入框架（如Robotlegs或Swiz），它将有一个单独的对象来处理实例化，存储和返回模型和服务对象的实例（在Robotlegs的情况下，它还将为您创建Command对象）并可以创建名为Mediators的视图管理对象。如果你不使用这些框架之一，你需要“自己动手”，如果你没有建筑思想，这可能有点困难。

有些人不知道如何自己动手（例如编写旧版Cairngorm的人）倾向于依赖单身人士。这些在当今时代并不是一种良好的做法，特别是如果您对单位测试工作感兴趣。 http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/

Answer 2

很大程度上取决于您拥有多少数据，从服务器刷新多少次，以及您必须支持更新和查询。

3号（和2号）基本上是单例 - 它往往最适合大型应用程序和大型数据集。是的，维护自己会很复杂，但这就是人们倾向于使用框架（puremvc，cairgorm等）的原因。很多复杂性都是为你处理的。在框架内缓存数据还可以提高性能和响应时间。

1的问题在于，如果必须协调每个组件的数据更新，则基本上需要编写无状态UI，始终在每个组件可见性上从服务器检索数据。

编辑：我正在使用cairgorm - 拥有~30个域模型（200个左右的远程调用）并且还使用视图模型。我的一些模型（远程对象）拥有数以万计的对象实例（记录），我保留了一个缓存/写回。所有复杂性都封装在控制器/命令中。表现可以接受。

Answer 3

就纯粹的表现而言，所有三个表现应该大致相同。你当然会通过拥有更多的RemoteObject实例来使用更多的内存，并且有一些额外的字节与你使用给定的RemoteObject实例向服务器发出的第一个请求一起发送（AMF协议的一部分） ）。但是，这些东西的影响可以忽略不计。因此，Amy是正确的，你应该根据易维护性而不是性能做出选择。