C# Win Forms. Passing values

Question

I have multiple winforms which interact with each other. One form allows the user to enter a set of properties and then validates them and with a button click moves onto the next form. The user may choose to back out and go to the previous form at any point of time.

I have a Business Object Class that records values for essential properties.

Now originally, I was using simple, naïve parameters to exchange values between forms. For example, lets say Form1 and Form2. On button click "Next" Form1 is hidden and Form2 is displayed:-

   // event of button click "Next" on Form1.cs //
    private void btnNext_Click(object sender, EventArgs e)
    {
        Form2 form2 = new Form2 (myTxtBoxValue.Text);
        form2.Show();
        this.Hide();
    }


    // constructor in Form2.cs //
    public Form2(string myTxtBoxValue)
    {
        InitializeComponent();
        TransactionBO trans = new TransactionBO();
        trans.myValue = myTxtBoxValue;  // <-- this gets the value accurately. 
    }

    // my Business Object class is called TransactionBO.cs //
    class TransactionBO
    {
       public string myValue {get;set;}
    }

However, it was suggested to me that a better way of doing this would be to use singletons. The reason, 'it is better not to bind form2 to form1, creating dependencies might reduce flexibility/scalability in the future'.

Can someone explain to my why? and how may I use Singletons (I know what Singletons are in its basic principle, do I have to create a separate singleton class or can I use my TransactionBO.cs class to pass values between forms)?

Answer 1

Let's address your colleagues' concerns about dependencies.

Just to level set, let's look at some topological graphs. Imagine that these are dependency graphs.

Your current design, depending on the details, will have a dependency graph that is either a line, a mesh, or is "fully connected." All of these graphs have the property that code changes at any single node in the graph will require the examination and possibly changes in numerous other points, and in some cases all of them will have to be looked at. This is bad.

What we'd prefer is a simpler graph. A tree, for example, is much simpler. but the very best is the star. In the star graph, you have only pairwise dependencies; a change to any one node requires the examination of at most one other node. This means that there is far better isolation and resilience to modification.

So, how do we get a star graph in your case? Here's how I would do it.

1. Define a new class that represents the overall workflow. If it's a workflow to enroll in a service, for example, you might call it EnrollmentWorkflow. in this example I'll just call it Workflow.

2. Give Workflow a series of fields and public properties that represent every data item you need to collect from the user.

3. In the code that starts the multi-step user interface, create a new Workflow instance and pass it to the first form's constructor.

4. In the event handler that fires when the user finishes a form, add code to copy all of the form's fields into properties of the Workflow. Then instantiate the next form, passing the same Workflow instance in the constructor.

5. In the next form, you can read all of the values needed from the Workflow object.

6. Continue like this until the last step is completed, at which point you would pass the Workflow to your business logic layer for processing.

7. If you like, you can add helper methods to the Workflow for things like data lookup, field validation, etc. so that they are all contained in one place.

8. If a user needs to save progress and resume later, it is a pretty simple matter to persist the Workflow as a serialized object, with only a small amount of work.

In the end, the Workflow object will be the center of the star graph, and the forms will be the nodes on the perimeter. This way you end up with a nice, simple dependency graph, and a good design that is easy to modify.