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...
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.
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 thePerson
class, but certainly not inside yourProgram
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.Take a look at the Mediator design pattern.