CodeSmith is a template-based code generator that automatically generates high level code (C#, VB.NET, ...). The current release features LINQ to SQL templates and supports Visual Studio 2008 Beta 2.
CodeSmith templates are coded in an ASP.NET like syntax, which allows .NET developers to write templates in one of the following languages:C#, VB.NET or JScript.NET. The templates define what will be generated by the CodeSmith generator. The generated code may be customized by the use of properties. Properties may be any .NET object, ranging from a simple boolean value to the representation of database metadata.
CodeSmith provides LINQ to SQL templates since release 4.1.0, which added the following features:
- Microsoft Visual Studio 2008 “Orcas” Support – CodeSmith has been updated to support the latest version of Visual Studio codenamed “Orcas”.
- Linq to Sql templates – Generates LINQ classes as well as manager classes to make it easier to execute common queries, manage validation, and add business rules. It’s “SQL Metal” on steroids.
- New Schema Providers – Contributed from the CodeSmith community, the MySQL and Oracle schema providers now included.
The current release includes "updated LINQ templates to work with Visual Studio 2008 Beta 2". Although Visual Studio 2008 provides a visual designer, which helps to create SQL to LINQ mappings, the code generation approach of CodeSmith has some advantages:
- You are in complete control of how mappings are generated.
- The generation of mappings may be incorporated into your build process. CodeSmith features a console generator and supports MSBuild.
- Changes to the database scheme are automatically synchronized with your source by starting a new build or generating code manually.
David Hayden compares the designer and the code generation approach in his post on Code Generation using CodeSmith - v4.1 - Visual Studio 2008 Support and LINQ to SQL Templates and comes to the following conclusion:
Although the LINQ to SQL Visual Designer is very cool and very productive, I have been burned badly by Visual Designers in the past and would prefer to have each LINQ to SQL Entity in its own non-visual designer file just like every other class in Visual Studio.
What do you think?