Inheritance and Templates

One of the most valuable things about templates written in .NET code of any style is the ability to use inheritance. This is classic inheritance where local state allows you to push functionality into base class methods that would become cumbersome and have excess dependencies if treated as external utility methods.

Inheritance also allows polymorphism, which is nothing more than a big word for exchangeability – OK, that’s actually a bigger word. Templates are called by something. Life is simpler and harnesses practical if that something is known and predictable, thus it’s logical to have an interface in a common location as a contract to the template interface. If the base class implements this interface and provides functionality via MustInherit/abstract members, there’s further capacity for evolution.


There are three assemblies involved. The template interface is in a common assembly available to all other assemblies. The base classes are in a support assembly which can be reused across many template sets. The templates themselves are in a separate assembly. For now, I have all templates associated with a project in one assembly, but I may change that to isolate the SQL and the .NET templates. In any case, these template assemblies are sets of templates that work together.

Inheritance let’s you push common functionality into the base class. Now that we have extension methods they offer an additional mechanism to remove common functionality from the leaf class. I know Scott Hanselman has said he’ll cut off the pinkies of anyone who uses extension methods on classes you own, and I’ll show you when I get to that in a few days why I disagree (although it’s in the DRN TV show). But that explains why my base classes are focused on state more than functionality. The key state issue is what you’re currently working on. In a template, state is metadata. In a .NET template, the important metadata is the definition for the entity you’re currently creating. In my templates, the ObjectData member of the DotNetBase contains this information.


Stay tuned for the distinction between the input data you’re working on and the thing you’re creating, which explains some of those other members.

Leave a Reply

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