有没有更好的方法来通过向导对话框处理进度?
我正在开发一个现有的向导对话框,该对话框作为选项卡式页面控件(隐藏选项卡)实现。向导的步骤以枚举类型定义。当用户单击导航按钮时,当前步骤将通过 switch 语句运行。开关的每个分支都充满了附加的分支逻辑(if/then/else),它保存各种用户选择的状态并分配下一步(不一定是顺序的,也不一定与显示的选项卡页一致)用户)。
当当前步骤被修改时,它会触发一个额外的 switch 语句,该语句会更新 UI(更改选项卡页、启用/禁用控件等)。
在实现时,向导对更改非常敏感,并且需要大量调试。我忍不住觉得有更好的设计方法。有什么建议吗?
I'm working on an existing wizard dialog which is implemented as a tabbed page control (with the tabs hidden). The steps of the wizard are defined in an enumerated type. When the user clicks a navigation button the current step is run through a switch statement. Each branch of the switch is filled with additional branching logic (if/then/else) which saves the state of various user choices and assigns the next step (which isn't necessarily sequential and doesn't necessarily coincide with the tab page displayed to the user).
When the current step is modified it triggers an additional switch statement which updates the UI (change tab page, enable/disable controls, etc.)
As implemented the wizard is very sensitive to changes and requires a lot of debugging. I can't help but feel there is a better way to design it. Any suggestions?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我没有足够的代表来添加评论,所以我必须将其作为答案发布,但事实并非如此!来自之前的 stackoverflow 帖子:
简化丑陋嵌套 if 的方法-C# 中的其他树
我只是认为它可能是相关的。
I haven't got enough rep to add a comment so i'll have to post this as an answer which it isn't! From a previous stackoverflow post:
Methods of simplifying ugly nested if-else trees in C#
I just thought it might be relevant.
此时,我的建议是构建一个小型概念验证 (poc),以表明您可以将当前形式的向导迁移到设计更完善的系统。从开发的角度来看,我建议构建 poc 以匹配用户在名称和元素方面看到的内容。此外,您还需要记录对象传递到每个页面时的状态,以防用户回溯或执行其他操作。另一个可能有帮助的领域是实现规则引擎,例如 DROOLS 或我上次检查的 JBoss 规则。有一种我当时不记得的算法也确实有助于提高性能。回顾一下:
1)创建一个小poc
2)使用具有状态的对象
3)寻找一个好的规则引擎
4) 获得批准才能做所有这些事情。
我应该补充一点,我意识到你之前在整个重写过程中被烧伤了,但这只是一个模块而不是整个企业。
At this point in time my recommendation would be to build a small proof of concept (poc) to show that you can migrate the wizard in its current form to a more well designed system. Looking at it from a development point of view, I would suggest building the poc to match what the user sees in terms of names and elements. Additionally you will need to record the state of the object as it is passed around to each of the pages, in case the user back tracks or does something else. Another area that might help is to implement a rules engine such as DROOLS, or JBoss rules as it goes last I checked. There exists an algorithm that I can't recall at the time that will really help with performance as well. So to recap:
1) Create a small poc
2) Use objects that have state
3) Look for a good rules engine
4) Get approval to do all of these things.
I should add I realize you were burned before on the whole re-write thing, but this is only a module not the entire enterprise.
我最近在我们的应用程序中实现了一个设计来解决类似的问题。我们的应用程序适用于需要多种步骤组合才能完成的工作流程。
作为一般的起始规则,我决定步骤本身不存储信息。他们也不被允许互相交谈。它们具有指向保存信息的模型对象的指针。我不遵循 MVC 或 MVP 模式,但我确实将模型与 UI 相当严格地分开。
每个工作流步骤都有一个需要实现的
OnEnter(boolforward)
和OnExit(boolforward)
方法。在这些中,您查询模型以更新您的控件,反之亦然。从一个步骤移动到另一个步骤是由
StateEngine
完成的,它保留所有已完成步骤的堆栈,当按下后退按钮时,当前状态为Exited,前一个是
Enter
ed。引擎有默认顺序的概念,因此大多数步骤只是要求 StateEngine 移动到下一步,无论它是什么,但如果你要求它移动到特定的步骤,它就会做那。在此设计之前,主要的维护难题是工作流程中的后退,而在此设计中几乎自动修复了这一问题。该设计并没有解决世界饥饿问题,但它使向导代码保持易于管理。
I recently implemented a design in our application to solve a similar problem. Our application works with workflows that require a variable combination of steps to complete.
As a general starting rule, I decided that the steps themselves don't store information. They are not allowed to talk to each other either. They have pointers to Model objects that hold the information. I don't follow either the MVC or MVP patterns, but I do keep the Model separted from the UI fairly strictly.
Each workflow step has an
OnEnter(bool forward)
andOnExit(bool forward)
method that they are required to implement. In these, you query the Model to update your controls or vice versa.Moving from one step to the other is done by an
StateEngine
It keeps a stack around of all the steps that were completed, and when the back button is pressed, the current state isExit
ed and the previous isEnter
ed. The engine has a notion of the default order, so most steps just ask theStateEngine
to move to the next step, whatever it is, but if you ask it to move to a specific one, it will do that.Before this design, a major maintenance pain was stepping back in the workflow, that was almost automatically fixed in this design. The design did not solve world hunger but it keeps the wizard code managable.
在我的职业生涯中,我用许多不同的语言创造了大量的巫师。通常对我来说更有效的是拥有某种父容器并且每个步骤都在不同的类/组件中。触发机制(下一个-上一个类型按钮)向管理器发送消息以替换容器中的内容。
现在我正在做另一个向导,这次我使用 Actipro 的 WPF 组件,它看起来不错。简单有效。
I've made tons of wizards in my career, with many different languages. Usually what worked better for me was to have some kind of parent container and each step in a different class/component. The trigger mechanism (next-prev type buttons) sends a message to the manager to replace the content in the container.
Right now I'm doing yet another wizard, and this time I'm using a WPF component from Actipro and it looks good. Simple and effective.