Question

I have a class which models online campaigns i.e. people clicking through to the site from affiliate websites, and we need to record all these clicks and any purchases that are made. This class has the usual crap – name, start date, end date etc. – which we need to return and I have a constructor which populates these values. All very standard and all very fine. I’ve done all the standard GetAll and GetById functions which use that constructor to populate the object.

However, in one case I need to return a list of the campaigns with their totals e.g. total clicks, total purchases etc. These clicks / purchases are stored in a separate DB table and the totals will be calculated using an SQL aggragate function. I could call a function which would get the total clicks and then another to get the total purchases for each campaign as we loop through them, but that would mean two extra database calls for each campaign returned.

Another option would be to always return the totals when you search for a campaign, but this is putting unnecessary work on the DB as the clicks table could get quite large quite quickly and doing aggregate functions on that wouldn’t be a good idea.

I finally thought of declaring public properties totalClicks and totalPurchases which aren’t populated in the constructor, but only when you call the specific GetTheTotals function. This is grand, but it means that when you are accessing an instance of the campaign object you could try objCampaign.totalClicks even though it is probably not set.

I know I could just return a dataset, but that just doesn’t seem right from an object oriented point of view. Any idea what the correct approach is here?

Answer 1

Lazy loading and batch loading are often in opposition to one another. The former is useful when you anticipate that accessing detail fields will be an infrequent operation – and allows you to avoid unnecessary work. However, if the cost of fetching the details for one object vs. all object is low – then it may make sense to simply batch load all of the information.

You can combine these behaviors – and implement batch lazy loading.

To do so, you would need to tie all data-carrying objects together, so that when one is asked for its aggregate totals you can fetch those totals for all objects.

A common design for this kind of problem is to store the aggregate details in a separate helper object (often organized into a dictionary based on some primary key). Initially the helper object is not populated – but when a request comes in from one instance you load the data for all instances.

Here’s a skeletal example of what I mean:

class CampaignInfo
{
   public int Key { get; set; }
   public string Name { get; set; }
   public DateTime StartDate { get; set; }
   public DateTime EndDate { get; set; }
   // etc...

   // initialized on construction all CampaignInfo instances share reference
   private AggregateDetails _details; 

   public int TotalClicks
   {
       get { return _details.TotalClicksFor( this.Key ); }
   }

   public int TotalPurchases
   {
       get { return _details.TotalPurchasesFor( this.Key ); }
   }
}

class AggregateDetails
{
    private class AggregateInfo
    {
        public int TotalClicks;
        public int TotalPurchases;
        // etc...
    }

    private readonly Dictionary<int,AggregateInfo> _cachedInfo;

    public int TotalClicksFor( int key )
    {
        if( _cachedInfo == null )
            LoadAggregateInfo(); // loads aggregates for all campaigns
        return _cachedInfo[key].TotalClicks;
    }

    public int TotalPurchasesFor( int key )
    {
        if( _cachedInfo == null ) 
            LoadAggregateInfo(); // loads aggregates for all campaigns
        return _cachedInfo[key].TotalPurchases;
    }

    // etc...
}

Obviously this code requires error and exception handling, some means to manage concurrency (so that calls to fetch data are thread safe), a means to track which campaigns keys to load data for, a mechanism to query the database, and so on. But it should give you an idea of how to structure your implementation to get the best of both worlds.