views:

99

answers:

3

Below is a Class I created to track the current Person in my glorified Data Entry and retrieval app. Once they select a person it calls the constrtuctor which then calls the database to fill in all the rest of the info. Also, throughout the program they will be able to change the various fields.

With this in mind do I have the below set up correctly? I am inexpierenced with properties and using Objects to store data across multiple forms and would appreciate any insight.

Thanks!

class CurrentPerson
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string MiddleName { get; set; }
    public string SuffixID { get; set; }
    public string TitleID { get; set; }
    public string SocialSn { get; set; }
    public string BirthDate { get; set; }
    public string Gender { get; set; }
    public string DlNumber { get; set; }
    public string DlStateID { get; set; }
    public string PrimaryRace { get; set; }
    public string SecondaryRace { get; set; }
    public string EmailAddress { get; set; }
    public string MaritalStatus { get; set; }
    public string InsertProgram { get; set; }
    public string InsertUserID { get; set; }
    public string UpdateProgram { get; set; }
    public string UpdateUserID { get; set; }
    public string LockID { get; set; }

    public int PersonID { get; set; }
    public int ClientID { get; set; }
    public int ResidencyCountyID { get; set; }
    public int ResponsibilityCountyID { get; set; }

    public bool HispanicOriginFlag { get; set; }
    public bool CitizenFlag { get; set; }
    public bool VeteranFlag { get; set; }

    public DateTime DeathDate { get; set; }
    public DateTime InsertDateTime { get; set; }
    public DateTime UpdateDateTime { get; set; }

    // Put the default Constructor back in
    public CurrentPerson(){}

    // Custom Constructor that needs the PersonID
    public CurrentPerson(int pID)
    {
        PersonID = pID;

        // Methods to get rest of data here
    }
}
+3  A: 

yup, looks good. you can, btw, set access on the get/set as well, to make it read/write only publicly

public DateTime DeathDate
{
    get;
    private set;
}
Muad'Dib
If I have private set can I still set the variable from my form?
Refracted Paladin
you can still use the variable on your form, you just can not assign to it--your code won't compile.
Muad'Dib
Through a constructor then would be the only way to set if it is private? Thanks!
Refracted Paladin
Any member of the same class can set a private property. External classes and methods can't set a private property.
Josh G
Thank you! I guess I couldn't have private setters then...
Refracted Paladin
+1  A: 

This is technically fine. They are all declared perfectly well.

However, often, with DB apps, you'll want to not use automatic properties, since property setters are often a great place to do some validation, as well as potentially marking properties/objects as "dirty" and requiring saving of some sort.

Reed Copsey
So a standard property setup would be more useful?
Refracted Paladin
It can be. It depends on what you're doing. Standard properties provde you more control - auto-properties are just a short-cut to make implementing properties simpler. If you want to do any validation, logging, etc - standard properties provide the means to do this directly. However, if you just want to use your property like a field, then auto-properties are great. Also, as Chris mentioned, you can use different access levels for get/set with standard or auto properties.
Reed Copsey
+1  A: 

The auto property is always get and set, so that you have no control about properties set (to mark the instance as dirty, or whatever). Therefore, while this is an acceptable class as data entity only, I usually find that auto properties are only rarely really applicable.

Lucero
Are you saying I would be better served with a standard property with a backing field?
Refracted Paladin
Yes, that's what he is saying.
Josh G
What I mean is that I seldom have situations where I really have no extra code in the setter, so that I cannot use auto properties. So yes, in these cases I need a backing field of course.
Lucero