2009-01-29 78 views
0

我可以在我开发的一款软件上使用一些建议/帮助。关于图案/设计的建议

该应用程序是一个向导式应用程序,用户在选择转到下一个表单或返回到前一个表单之前填写每个表单上的字段。相当简单。

现在菜单调用frmWiz1(InitialData),当frmWiz1返回DialogResult.OK时,菜单将调用frmWiz2(frmWiz1.Data)(不完全是,它存储了每个表单的所有数据,并将这些引用传入到下一个表格)。每个数据对象从IPrintable接口入侵,定义自身打印的方法,因此在向导的最后一页(print preview/sign)中,它将每个Data对象添加到只遍历数据对象的自定义PrintDocument对象,并调用它们打印功能和管理分页等

最初,我认为这是一个好主意,但现在我在想: - 菜单表单处理过多的流程逻辑。 - Data对象(处理应用于其特定数据集的所有业务逻辑)应与打印逻辑分离(原因是因为它们现在在打印命名空间中 - 可能只是重新定位会将我的放心)。

我不知道。我对语言很体面,但我仍然是设计的新手。

回答

2

螺丝“frm”前缀!

关于应用程序的整体流程,我建议使用Application Controller或其他类型的东西来集中逻辑。

就用户界面而言,每个向导阶段应该是一个单独的用户控件(没有“取消”,“完成”,“下一步”或任何按钮),这些按钮将放置在根窗体上。

没有对象应该负责打印本身 - 使用IPrinterService这样做。

+0

我最终实现了类似于应用程序控制器的东西(它必须要做直到我的poeaa书到达)。至于对frm前缀的厌恶,他们留下来! – 2009-02-09 17:43:18

1

短短几年一般几点思考:

  • This is a great Wizard control.我们在这里使用它在工作,我必须说这家伙没有一个真正的好工作吧。不知道它是否对您有用,但请查看

  • 找出您需要了解的对象以便打印它。尝试想出方法和/或事件,您需要一个对象才能“打印”。把它们放到一个接口中,让你的业务对象实现这个接口。然后,让您的打印助手类严格处理接口。