Good class design by example

Question

I am trying to work out the best way to design a class that has its properties persisted in a database. Let's take a basic example of a Person. To create a new person and place it in the database, I want the DateOfBirth property to be optional (i.e. NULLable in the DB).

Here's my sample code:

namespace BusinessLayer
{
    class Person
    {
        public string FirstName { get; set; }
        public string LastName { get; set; }
        public DateTime DateOfBirth { get; set; }
    }
}

I'm unsure as to whether the fields should be public or not. Should I do it like this:

class Program
{
    static void Main(string[] args)
    {
        Person person1 = new Person("Kate","Middleton",null);
    }
}

or like this:

class Program
{
    static void Main(string[] args)
    {
        Person person1 = new Person();
        person1.FirstName = "Kate";
        person1.LastName = "Middleton";
    }
}

I'm also wondering how I should be dealing with the optional properties of the class. Once the fields have been populated how do I then save them to the DB? I have a DatabaseComponenet class to save the information. How do I deal with the optional when saving to the database?

So, would I do something like this:

public int Save()
{
    int personId;
    personId = DatabaseComponent.InsertPerson(FirstName, LastName, DateOfBirth);
    return personId;
}

Thanks for any help! Some useful URLs on good class design would also be appreciated.

Answer 1

First, I'd put two distinct public constructor to Person:

namespace BusinessLayer {     class Person     {         public Person(string firstName, string lastName): this(firstName, lastName, DateTime.Now)         {}          public Person(string firstName, string lastName, DateTime birthDate)         {             FirstName = firstName;             LastName = lastName;             DateOfBirth = birthDate;         }          public string FirstName { get; set; }         public string LastName { get; set; }         public DateTime DateOfBirth { get; set; }     } } 

this allows you to write both

var p = new Person("Marilyin", "Manson"); var p2 = new Person("Alice", "Cooper", new DateTime(...)); 

and

var p = new Person { FirstName="Marilyn", LastName="Manson" }; 

I can't see why you should limit to only one form.

As for the DatabaseComponent I'd strongly suggest to write a method that allows you to save a Person instead of the signature you are implicitly declaring.

That's because, should one day change the way a Person is defined, you'd probably have to change the code in each point you invoke Save() method. By saving just a Person, you only have to change the Save() implementation.

Don't you plan to use an ORM by the way?

Answer 2

With C# 3.0 class initializers I no longer bother of providing a constructor that allows me to initialize all properties:

var person1 = new Person {     FirstName = "Kate";     LastName = "Middleton"; }; 

As far as the Save method is concerned I usually put them in a separate repository class:

public int Save(Person person)  {     ... } 

and then when I need to save a person I do:

var person1 = new Person {     FirstName = "Kate";     LastName = "Middleton"; }; var id = new PersonsRepository().Save(person1); 

Answer 3

Only use constructors if some fields are mandatory since it's an effective way to make sure that those fields are specified.

I'm unsure as to whether the fields should be public or not

Fields usually means member variables and those should always be private. As for properties I would stick with get/set for database objects.

I'm also wondering how I should be dealing with the optional properties of the class. Once the fields have been populated how do I then save them to the DB?

Saving things to the database is a whole different story. I would not try to invent my own layer but to use an existing one. There are a whole set of different ORM:s out there from very simple to very feature complete.

Take a look at PetaPoco for a lightweight alternative or nHibernate for a more feature complete alternative.

Validation

One common way to make sure that mandatory fields are correctly specified and got valid values are to use a validation framework. There is one built into .net called DataAnnotations. Google it and look at some examples.