Retrieve Saved Settings from DB in Constructor or Method?

Question

I recently inherited a project that includes and assessment portion, where you are asked a series of T/F questions and the responses are saved to a database. The requirements have now changed and I need to retrieve those answers later in the process. In other places in this project the classes have a call to a data access object (DAO) in each GET - that seems clunky and slow to me since that is a lot of DB server trips if I have to get 20-30 answers. It seems better to me to have one call to the DB and then fill all the properties in memory.

Assuming I have a class like this

public class Assessment
{
    // Property Variables like private bool _needSearchAssistance;
    // Accessor Methods - Typical Get{} Set{}
    // Constructor
    public Assessment()
    {
    }
        public void SendResultsEmail(EmailAddress email)
        {
      // Typical SMTP stuff
        }
        public void Save(int ParticipantId)
        {
            //Instantiate DAO and save to DB
        }
}

Does it make more sense to use an overloaded constructor like:

public Assessment(int ParticipantId)
{
    //Instantiate DAO and get values to fill props.
}

Or leave the constructor alone and create a function like

public void LoadFromDb(int ParticipantId)
{
    /Instantiate DAO and get values to fill props.
}

If you use the function approach, is there a typical or standard 'naming convention' for this type of function. So far LoadFromDb is the best I can think of.

Answer 1

Can't you use some sort of Database object that has the connection to the database and pass that onto this class so it can use it's connection ? If it's not open yet you can open it if needed !

This will give you more options as well, as you can implement some sort of IDatabase interface if you ever need this class for other databases as well.

Answer 2

I've tended to go with a method that retrieves the data, e.g. LoadPreviousResponses. It simplifies testing and isolates the functionality. Make it private if you don't want to share. An overloaded constructor can invoke the method if it makes sense, e.g. when the ParticipantId is provided.

Another option is to create the empty instance and delay loading all of the appropriate data until the first Get invocation on any property that requires DB access. At that time you can retrieve all of the data in one round trip to the database and populate the remainder of the instance. If no one asks for details then you've saved the cost.