Blogging the AZDNUG: CodeSmith - Part 2

[7:15pm]

Generating Business Logic
CodeSmith generates classes for each table. These classes have relationships just like the tables have relationships. Each class' properties directly correspond to the fields in the DB table. These classes can be generated to either generate SPROCS or inline SQL. Ish was smart and avoided the Sproc/DA Query argument entirely, mostly for fear of igniting a war in the room. Good thing Rob Howard and Frans Bouma weren't here.

Right now, Ish is showing us how to add XML comments to each template. It's really cool how the CodeSmith IDE picks up the properties automatically and drops them into the properties window. That's pretty cool. The template that he's showing us even adds the execute permissions for the current user.

I'll tell you what, this guy knows CodeSmith cold. He even generated templates that add NUnit fixtures, methods, and namespaces. Thanks to Jamie Cansdale, I'm getting started into the Unit Testing world, so that ought to be interesting.

The biggest problem with code generators IMO is your inability to customized the code if you have to regenerate. Ish gave us a very common sense solution to that problem, by generating everything as base classes, and make your modifications to inherited classes. I had never thought of that, but I probably should have. It totally makes sense.

So far I'm liking how this thing works. I'm not sure how I feel about it in regards to other systems that I've seen/used (XHEO|Enterprise, LLBLGenPro, Etc), but it's been great. Gotta run, time for Pizza.

1 Comment

  • "The biggest problem with code generators IMO is your inability to customized the code if you have to regenerate. Ish gave us a very common sense solution to that problem, by generating everything as base classes, and make your modifications to inherited classes. I had never thought of that, but I probably should have. It totally makes sense."

    True, that's called the strategy pattern: generate common code as base classes, offer abstract methods where details have to be filled in and if you can, generate those details. I use that too: I have a generic library which is customized by generated code (which fills in the blanks).



    The real problem with code generators is the construction of the templates :) LLBLGen Pro also uses a template based generator system (which uses a NAnt structure so you can add your own code generating assemblies as well to produce code/alter things) and what I found out was that the most efficient way of writing templates is from existing code: thus first write the code in full (for example the code for 3/4 classes) then write the templates using that code. So, if there aren't templates which fit your needs, you have to get your hands dirty and have to spend a lot of time getting it right.

Comments have been disabled for this content.