多个 RemoteObjects - 最佳实践
我有一个包含大约 20 个模型和控制器的应用程序，并且没有使用任何特定的框架。在 Flex 性能方面使用多个远程对象的最佳实践是什么？
1) 方法 1 - 每个组件一个 - 每个组件为自己实例化一个 RemoteObject
2) 方法 2 - 应用程序根中的多个 - 每个控制器由根中的一个 RemoteObject 处理
3) 方法 3 - 应用程序根目录中的一个 - 将所有控制器组合到一个类中并使用一个 RemoteObject 处理它们
我猜 3 将具有最佳性能，但维护起来会太混乱，而 1 会是最干净但是会受到性能影响。你怎么认为？
I have an application with about 20 models and controllers and am not using any particular framework. What is the best practice for using multiple remote objects in Flex performance-wise?
1) Method 1 - One per Component - Each component instantiates a RemoteObject for itself
2) Method 2 - Multiple in Application Root - Each controller is handled by a RemoteObject in the root
3) Method 3 - One in Application Root - Combine all controllers into one class and handle them with one RemoteObject
I'm guessing 3 will have the best performance but will be too messy to maintain and 1 would be the cleanest but would take a performance hit. What do you think?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
最佳实践是“以上都不是”。您的视图应该调度控制器或命令组件用来调用您的服务的事件，然后在返回数据时更新您的模型。您的视图将绑定到数据，然后视图将自动使用新数据进行更新。
我的偏好是为我正在检索的每个不同数据或类型的数据提供一个服务类 - 这使得构建模拟服务变得更容易，这些模拟服务可以根据您正在执行的操作根据需要交换为真实服务（例如，如果您有复杂的服务器设置，从事蒙皮工作的开发人员会使用模拟）。但实际上，如何做到这一点取决于个人喜好。
那么，您的服务位于哪里，以便控制器或命令可以访问它们？如果您使用依赖注入框架，例如 Robotlegs 或 Swiz，它将有一个单独的对象来处理模型和服务对象的实例化、存储和返回实例（在 Robotlegs 的情况下，它还会为您创建 Command 对象）并可以创建称为中介者的视图管理对象）。如果您不使用这些框架之一，则需要“推出自己的框架”，如果您没有架构意识，这可能会有点困难。
不知道如何自己开发的人（例如编写旧版本 Cairngorm 的人）往往会依赖的一件事是单例。在当今时代，这些不被认为是好的实践，特别是如果您对单元测试您的工作完全感兴趣的话。 http://misko.hevery.com/code-审稿人指南/flaw-brittle-global-state-singletons/
Best practice would be "none of the above." Your Views should dispatch events that a controller or Command component would use to call your service(s) and then update your model on return of the data. Your Views would be bound to the data, and then the Views would automatically be updated with the new data.
My preference is to have one service Class per different piece or type of data I am retrieving--this makes it easier to build mock services that can be swapped for real services as needed depending on what you're doing (for instance if you have a complicated server setup, a developer who is working on skinning would use the mocks). But really, how you do that is a matter of personal preference.
So, where do your services live, so that a controller or command can reach them? If you use a Dependency Injection framework such as Robotlegs or Swiz, it will have a separate object that handles instantiating, storing, and and returning instances of model and service objects (in the case of Robotlegs, it also will create your Command objects for you and can create view management objects called Mediators). If you don't use one of these frameworks, you'll need to "roll your own," which can be a bit difficult if you're not architecturally minded.
One thing people who don't know how to roll their own (such as the people who wrote the older versions of Cairngorm) tend to fall back on is Singletons. These are not considered good practice in this day and age, especially if you are at all interested in unit testing your work. http://misko.hevery.com/code-reviewers-guide/flaw-brittle-global-state-singletons/
很大程度上取决于您拥有多少数据、从服务器刷新数据的次数以及您必须支持更新和查询。
3号（和2号）基本上是单例——这往往最适合大型应用程序和大型数据集。是的，自己维护起来会很复杂，但这就是为什么人们倾向于使用框架（puremvc、cairgorm 等）。大部分复杂性都已为您处理。在框架内缓存数据还可以提高性能并缩短响应时间。
1 的问题是，如果您必须协调每个组件的数据更新，那么您基本上需要编写一个无状态 UI，始终从服务器检索每个组件可见性的数据。
编辑：我正在使用 cairgorm - 有大约 30 个域模型（200 个左右的远程调用）并且还使用视图模型。我的一些模型（远程对象）有数十万个对象实例（记录），我保留一个缓存/写回。所有的复杂性都封装在控制器/命令中。性能是可以接受的。
A lot depends on how much data you have, how many times it gets refreshed from the server, and of you have to support update as well as query.
Number 3 (and 2) are basically a singletons - which tends to work best for large applications and large datasets. Yes, it would be complex to maintain yourself, but that's why people tend to use frameworks (puremvc, cairgorm, etc). much of the complexity is handled for you. Caching data within the frameworks also enhances performance and response time.
The problem with 1 is if you have to coordinate data updates per component, you basically need to write a stateless UI, always retrieving the data from the server on each component visibility.
edit: I'm using cairgorm - have ~ 30 domain models (200 or so remote calls) and also use view models. some of my models (remote object) have 10's of thousands of object instances (records), I keep a cache with/write back. All of the complexity is encapsulated in the controller/commands. Performance is acceptable.
就纯粹性能而言，这三者的表现应该大致相同。当然，通过拥有更多 RemoteObject 实例，您会使用更多的内存，并且随着您使用给定 RemoteObject 实例向服务器发出的第一个请求，还会发送一些额外的字节（AMF 协议的一部分） ）。然而，这些事情的影响可以忽略不计。因此，艾米是对的，您应该根据易于维护性而不是性能来做出选择。
In terms of pure performance, all three of those should perform roughly the same. You'll of course use slightly more memory by having more instances of RemoteObject and there are a couple of extra bytes that get sent along with the first request that you've made with a given RemoteObject instance to your server (part of the AMF protocol). However, the effect of these things is negligible. As such, Amy is right that you should make a choice based on ease of maintainability and not performance.