I could use some advice/help on a piece of software I’ve developed.
The application is a wizard style app where users fill out fields on each form before choosing to go to the next form or back to the previous. Fairly simple.
Right now the menu calls frmWiz1(InitialData) and when frmWiz1 returns with DialogResult.OK the menu will call frmWiz2(frmWiz1.Data) (not exactly, it stores all of the Data from each form, and passes those references in to the next form). Each data object inherts from an IPrintable interface that defines methods for printing itself, so at the last page in the wizard (print preview/sign), it adds each Data object to a custom PrintDocument object that just iterates through the data objects, calling their print functions and manages pagination etc.
Initially I thought this was a good idea but now I’m thinking that: – The menu form is handling too much flow logic. – The Data objects (which handle all of the business logic that applies to their particular set of data) should be decoupled from print logic (cause as they are now, they’re in the printing namespace – maybe just a relocation will set my mind at ease).
I don’t know. I’m decent with the language, but I’m still a rookie at design.
Screw ‘frm’ prefixes!
With respect to the overall flow of the application, I would recommend using Application Controller or something of the kind in order to centralize the logic.
As far as the UI goes, each Wizard stage should be a separate User Control (with no ‘Cancel’, ‘Finish’, ‘Next’ or whatever buttons) wich is placed on the root form with the aforementioned buttons.
No object should be responsible for printing itself – use IPrinterService for doing that.