Thursday, May 29, 2008

New Data Layer for BitsDuJour

You might not know it to look at it, but we've just completed a major update to 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:
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

public bool DeletePermanently(MusicMailer MusicMailer) 
  return ReflectiveFactory.Instance.DeletePermanently

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


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.

1 comment:

  1. Hi there, Christian Jungers here from CM3 Consulting. We've been very excited working with Nico to integrate the aplha-release of DPL into his production websites (we've been using it for some of our clients over the past several months). We're also thrilled with how positive his experience has been with the DPL (as it has been for us).

    What we've really tried to create with the DPL, much in the spirit of the Enterprise Library from the Patterns and Practices group at MS, is an encapsulation of industry best practices for mundane tasks that developers all deal with. In other words, we saw ourselves solving the data access problem in exactly the same way over and over again with simple, tedious changes between each class and its specific fields.

    The DPL combines one-time uses of reflection (which is slow) with some pretty advanced mechanisms to cache all reflected work allowing our single data layer to function reflectively on any class you make with native performance in terms of speed! That may sound shocking or even unbelievable and we were shocked to find that it was possible in our early proofs of concept.

    After we realized that this idea worked, we began to implement some more advanced features into the DPL such as caching coherency (allowing multiple instances / applications to share the same data store and keep in sync with each other), collision detection (so that near-simultaneous writes to the same record can't happen and the DPL will notify the loser(s)), automatic version tracking (so that changes to an object are versioned and a complete history of those changes is available)... etc...

    All of these features have been implemented to support specific needs of our various enterprise and web application clients. In other words, the DPL is meant to standardize and simplify even a large scale enterprise application's data access. It can allow a developer (like Nico) to focus on the real meat of what they want to accomplish and not get bogged down in the extremely tedious details of data access. If also allows developers to explore new ideas far more easily because you never have to do anything but play with your code / classes. Once you have them written you already have ALL of your data access layer written for you! That alone has proven an interesting side benefit. We can now provide dynamic capabilities for web sites MUCH faster / cheaper than we could have in the past without any sacrifice of capabilities in the data layer.

    Anyhow, clearly we are just as proud of the DPL as Nico is happy with it! And we'd love to chat more if you have any questions or comments about it. We are looking to continue working with it as an Alpha for a bit longer this year... with hopes of a public release perhaps this fall.

    Thanks for listening! And Nico, thanks again for seeing the power of the DPL and taking it for a spin. :-)


Note: Only a member of this blog may post a comment.