Flash Builder 中的多页面数据库应用程序 - 如何访问/调用不同的屏幕？
我正在尝试创建我的第一个现实世界应用程序。它是 Flash Builder 4 中的数据库驱动（通过 Web 服务）应用程序。
该应用程序将具有 30 多个不同的数据输入表单屏幕、列表屏幕、搜索屏幕等，它们都使用不同的 Web 服务。
显然，我想将其拆分，以便随着应用程序的增长它是可管理的，并且应用程序尽可能快（如果必须加载所有元素，则初始加载可能会很慢，但我希望一旦用户“在”应用程序中）。
到目前为止我所采用的方法是拥有我的主应用程序（称为布局），然后拥有一个包含每个不同屏幕的 ViewStack。这很有效，但这意味着每次添加新屏幕时都需要维护相当多的代码（相关信息如下：从另一个组件交换应用程序中的 MXML 组件 - 可能吗？ ）
每组表单都是相关的，因此应用程序的“客户端”区域有一个数据输入表单，一些列表表单。我需要在加载时传递参数。 IE。 “加载 ID 为 123 的数据输入表单”。
目前我每个表单都有一个组件，即。客户表格和客户列表。这是一个好方法吗？我应该使用模块吗？
ViewStack 是一种有效的方法吗？
I am trying to create my first real world application. It's a database driven (via Web Services) application in Flash Builder 4.
The application will have over 30+ different data entry form screens, list screens, search screens etc that all use different web services.
Obviously I want to split this up so that it's manageable as the application grows, and so that the application is as fast as possible (initial loading can be slow if it has to load all the elements, but I want it to be fast once the user is "in" the app).
The approach I had up until now was to have my main application (called layout), and then have a ViewStack with each of the different screens on it. This works well, however it means there is a fair bit of code to be maintained each time I add a new screen (info on that is here: Swap MXML Component in Application from another Component - Possible? )
Each group of forms are related, so the "clients" area of the application has a data entry form, a few list forms. I need to pass parameters when it loads. ie. "Load the data entry form with the ID of 123".
At the moment I have a Component for each form, ie. ClientForm and ClientList. Is this a good approach? Should I be using Modules instead?
Is the ViewStack an efficient way of doing it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果我要开发这种类型的应用程序，我会拒绝视图堆栈并接受状态。自从 Flex 2/3 声明以来，它们变得更好了。与视图堆栈相比，状态的主要优点是您没有为子容器创建一些额外的容器/持有者。另一个优点是可以使用字符串标识符切换状态，您可以轻松地通过事件传递这些标识符，而无需在字符串标识符和视图之间使用某些映射。只需使用与状态名称相同的字符串即可。因此它将是松散耦合且相当模块化的。
另一个建议是尝试将您的应用程序尽可能分解为小的独立组件/类。尝试将对服务器的所有调用隔离到单独的操作/命令中。如果您愿意，可以使用一些架构框架（例如 Mate、Parsley 或其他框架；只需避免使用 Cairngorm 或 PureMVC）。
执行分析您的屏幕和通话。屏幕和呼叫的数量是否有限？将来有可能需要添加它们吗？它们多久添加一次？如果屏幕数量有限，将来添加一个/两个屏幕的可能性很小，您可以将所有状态放在一个 MXML 组件中，使用事件模型将视图本身提取到单独的组件中，以便通过自定义事件从它们获取反馈。如果有相当大量的视图，您可以形成一些视图层次结构，将状态分组到单独的子组件上，以获得可读（和可维护）的代码。
另一种策略是如果确实存在大量表单/视图并且可以在将来定期添加它们，则使用模块。在这种情况下，您应该提供一些带有模块描述的配置文件（我建议 XML 文件）。主应用程序加载该配置，然后决定如何加载和显示模块以及监听和反应哪些事件。
我希望上面列举的方向可以成为规划您的申请的良好起点。祝你好运！
If I'd develop such kind of application I'd reject view stacks and accept states. They are got much more better since Flex 2/3 states. The main advantage of states in comparison with view stacks is you haven't create some additional containers/holders for your child containers. Another advantage is a possibility to switch states using string identifiers which you can easily pass with your events without necessity to use some mapping between string identifiers and views. Just using the same strings as state names. So it will be loosely coupled and pretty modularized.
Another advice is try to break your application into small independent components/classes as it possible. Try to isolate all the calls to the server into separate actions/commands. You can use some architectural framework for that if you'd like it (like Mate, Parsley or something else; just avoid Cairngorm or PureMVC).
Preform analyzing your screens and calls. Is there a finite number of screens and calls? Is it probable they have to be added in future? How often they'll be added? In case of finite number of screens with rare possibility of adding one/two screens in future you can place all your states in one MXML component extracting views themselves into separate components using event model for getting feedback from them with custom events. If there are rather great amount of views you can form some hierarchy of views grouping states on a separate subcomponents to have readable (and maintainable) code.
Another strategy is using modules if there is really great amount of forms/views and they can be added in future regularly. In this case you should provide some configuration file (I suggest XML file) with modules description. The main application loads that configuration and then decided how to load and display modules and which events to listen and react.
I hope directions enumerated above can be good starting point to plan your application. Good luck!