views:

177

answers:

3

I have a fairly large CRUD winform app that is set up to display forms embedded in tabcontrols. I want to have objects for Person,(has a) Enrollment,(has a) Plan that hold and track the information as they interact with the forms. How do I accomplish this? I found a suggestion to declare the Person object in my Program.cs like so -->

internal static class Program
{
    public static CurrentPerson _CurrentPerson;

    /// <summary>
    /// The main entry point for the application.
    /// </summary>
    [STAThread]
    private static void Main()
    {
        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);
        Application.Run(new FrmWWCShell());
    }
}

and then on the Search.cs -->

 Program._CurrentPerson = new CurrentPerson
                                     {
                                         PersonID = Convert.ToInt32(pID),
                                         LastName = lName,
                                         FirstName = fName,
                                         SocialSn = sSN,
                                         MiddleName = mName,
                                         BirthDate = Convert.ToDateTime(bDate)
                                     };

Is this the best way? There is still a bunch of Data that needs to be filled in from the database once they have made this selection on the Search page. What about declaring the object on each form and passing it some way? The object is slowly "built" as they progress. First they Search for someone by name and select who they will work with. Then they can work with there Enrollments. After selecting an Enrollment they will be able to interact with there Plans.

I would be grateful for any guidance here as the scope of this has left my inexperienced head spinning...

+2  A: 

You will need to seperate your data, logic and GUI.

Look into the Model-View-Controller pattern.

If you think it's too complex in your case you might just create a central controller class to hold the central data. Pass on this object in every form constructor and you're done.

Gerrie Schenck
A: 

a) Singleton

A global static property is not such a good idea from the code reuse perspective. If you are planning to access a global static property from all over your code, you are making your code pretty tied to this specific application.

If there was always only a single instance of Person in your code, then you could place this Singleton inside the Person class, but certainly not inside your Program class. Note, however, that use of Singleton classes will usually be limited to logging service or something which is so widely common that it will surely never change.

b) Same object reference

In this case you don't need a singleton instance, but rather to pass the same reference to your data object (Person, or whatever it is) to each Form that is accessing it. If your Form is a representation of a part of your data, then you can pass only that part of data to the form, preferably through a simplest possible interface.

Changing the data in one form will probably need to update other forms. That is what Model-View-Controller and similar patterns help you accomplish - notifying views that the data has been changed somewhere else.

For example, by implementing the IPropertyNameChanged interface in your Person class, you can notify anyone interested (any Form), whenever a property is changed. Check this for an example: http://msdn.microsoft.com/en-us/library/ms229614.aspx. By attaching an event handler to that event in each form, you will notify all of them that they need to be invalidated.

Groo
Singletons are evil. They cause lots of problems if you try things like data binding. For example, binding to a Person object that is static inside a static class simply won't work.
Dmitri Nesteruk
I agree, I am sorry if I didn't make it clearer - I did say that having a global static property is a bad idea, but just wanted to state that placing it inside the static Program class is a *really* bad idea.
Groo
A: 

Take a look at the Mediator design pattern.

Mykola Golubyev