views:

111

answers:

2

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.

+1  A: 

Just a few general thoughs:

  • This is a great Wizard control. We use it here at work, and I must say this guy did a real good job with it. Not sure if it can be useful to you, but check it out

  • Figure out exactly what you need to know about an object in order to print it. Try to come up with methods and/or events that you would need an object to have in order to be "printable". Put those into an interface, and have your business objects implement that interface. Then, have your printing helper class deal strictly with interfaces.

BFree
+2  A: 

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.

Anton Gogolev
I ended up implementing something like Application Controller (it'll have to do until my poeaa book arrives). As for the aversion to frm prefixes, they stay!
SnOrfus