Using Codesmith with the Enterprise Library

I’ve always maintained that despite all their other foibles (real and imaginary), the sheer volume of cash flowing through Microsoft allows them the leeway to do some pretty amazing stuff. While I wouldn’t necessarily call the work of the Patterns and Practices group thought leadership, it is at the very least an incredibly thoughtful actualisation of some of the leading concepts in enterprise application architecture.

The Enterprise Library is the latest release from this group, and contains some extremely useful code blocks (namely Configuration, Data and Exception handling). The Logging block is another story entirely, producing absolutely abominable performance results in comparison to the leading light in .NET logging: log4net. And by abominable I’m talking about 10 seconds versus 10 milliseconds. I’d highly recommend doing your own performance testing before choosing the Microsoft Logging block over log4net. Then use log4net.

Setting aside the lesser application blocks, we’ve recently implemented the Data application block, which in conjunction with some funky code generation courtesy of CodeSmith, has reduced our data ‘plumbing’ code by perhaps fivefold.

Something that previously took 50-odd lines of code can now be represented thusly:

void UpdateOp(IDbTransaction transaction, DataSet data)
{
  ProductDataSet productData = (ProductDataSet) data;
  database.UpdateDataSet(
    data,
    productData.Product.TableName,
    Spuds.Product_Insert(CurrentUser.Guid),
    Spuds.Product_Update(CurrentUser.Guid),
    Spuds.Product_Delete(CurrentUser.Guid),
    transaction);
}

What you are seeing there is this:

  • Take a raw dataset and cast is as a typed dataset (so we can access the tables by name)
  • Throw it at the Enterprise Library database.UpdateDataSet command, along with wrappers for the CRUD stored procedures.
  • The individual Insert, Update and Delete stored procedures come from our code-generated class (Spuds).
  • Note that nowhere have we actually specified the values to send to the stored procedures (apart from the user ID for security/auditing). The mappings between the values in the dataset and the stored proc parameters are all handled in the generated code and the database object.
  • Any time any stored procs are added or changed, we can jsut re-run the code gen to regenerate the Spuds class.

To give you an idea of the time savings, previously we would have to manually code wrappers for each stored procedure, create a database connection and dataAdapter, then pass the dataset changes and the command wrappers to the dataAdapter to save.

A couple of caveats here:

  • We had to code the CodeSmith template ourselves, but it’s a one-off thing.
  • The column names in your typed datasets should match the SQL column names (this is automatic if you use the visual designer for your datasets anyway).
  • The enterprise data block relies on the enterprise configuration block, so your config files have to adhere to their specifications. No problem if you follow the examples.
  • The IDbTransaction parameter in the example above is not strictly necessary, but we’ve chosen this implementation so that we can pass any data access methods as a delegate to a base class method that creates and tidies up the transaction. That’s a story for another day.

6 Replies to “Using Codesmith with the Enterprise Library”

  1. Thanks for showing how to take the Enterprise Data Access Block to another level. Could you please provide an example of a Codesmith template. I just downloaded Codesmith and am trying to figure out how to make it work for me. – Claus

  2. Please provide us with more details. I’d love to implement what you have done but I need a little more direction and perhaps an example of the codesmith template you’ve created.

Leave a Reply

Your email address will not be published. Required fields are marked *