New Data Layer for BitsDuJour

You might not know it to look at it, but we've just completed a major update to BitsDuJour.com. The changes are all on the back end as we've moved over to a really fantastic back-end system using a pre-release version from the folks at CM3 called the "Data Persistence Layer", or DPL for short.

So let me explain briefly why the DPL is totally kick-ass.

1. We halved our back-end code
2. We never have to write a line of SQL again
3. Once you code a class the database tables are all created automatically
4. The database calls are all cached, so the pages load much faster
5. it's massively simplified our codebase
6. It's just, how can i say this: 'beautiful'

So that's not bad for the overview, I'll go into a little detail on how we set up our system to use the DPL here. First up we're using .Net, and always have done, and the DPL is native .Net code. It's built on top of Microsoft's Enterprise Library, so all the data access stuff is all done using best practices.

The way the DPL works is that you code up a class inheriting from the BaseDataObject. Any fields in that class are then used to create the database table that holds the data for that class. The great part is that you don't need to create the database table yourself or write any of the plumbing code, the table is created automatically by the DPL as soon as it needs to save it's first piece of data.

So here's a really simple example of a class with just one field:

[Serializable()] 
public class MusicMailer : BaseDataObject 
{
  string _Email; 
  public string Email { 
    get { return _Email; } 
    set { _Email = value; } 
  } 
}

So when it's needed the DPL creates a corresponding table that looks like this:



You'll see that we have an Email field, the DPL is creating that straight from the "string _Email;" declaration. There are also a whole bunch of other fields which the DPL needs to keep track of things including a MusicMailerId which is the unique Id for that record.

So when it comes to actually using your class the cleanest way is to create a Service class that will do all your creating, saving and deleting. It's a little more verbose, but I prefer doing this as then all my calls to the DPL are in one place.

public class MusicMailerService 
{ 

public MusicMailer CreateByEmail(string Email) 
{ 
  return ReflectiveFactory.Instance.FindBy
    <MusicMailer>("_Email", Email); 
} 

public bool SaveOrUpdate(MusicMailer MusicMailer) 
{ 
  return ReflectiveFactory.Instance.SaveOrUpdate
    <MusicMailer>(MusicMailer); 
}

public bool DeletePermanently(MusicMailer MusicMailer) 
{ 
  return ReflectiveFactory.Instance.DeletePermanently
    <MusicMailer>(MusicMailer); 
}

public List<MusicMailer> CreateList() 
{ 
  return new List<MusicMailer>ReflectiveFactory.Instance.LoadAll
    <MusicMailer>()); 
}

} 

This is a really simple example, but as you're in control of your classes you can write anything you want in there, extra properties, methods and whatever you need. You can mark fields as [NonSerializable()] if you don't want the DPL to serialize them to the database. There are also some powerful classes for defining search criteria.

As I said up the top this is a pre-release version of the DPL, we've been working with CM3 to alpha test what they've been building ahead of the early public release. If you ask really really nicely they might even get you a pre-release copy as they're looking for feedback.

So for us we're really happy to get this in place as it means that a lot of the things that we've had on the back burner for a while can finally get built out. So look forward to seeing a lot more features appearing over the next few months.