Anders Norås has some fairly sharp criticism of the Microsoft DSL book and tools:

Just like with the software factories provided by the Patterns and Practices team, the examples in the book are bad examples of what you should use a visual DSL for. ... The lead role in the story is played by Devika, a lead programmer at CJKW. ... The code generated by Devika's DSL is similar to the manual hacks CJKW had done to satisfy their clients before they discovered DSLs[:] procedural and repetitive.

In my rant on software factories I stated that we should prefer frameworks over code generation, and whenever we see a reoccurring problem we should try to commoditize it via a framework rather than through code generation to improve maintainability.

I'd tend to agree that I find many of the ways Microsoft suggest using their DSL Tools to be odd, and not really good examples of how or where to apply Domain-Specific Modeling. There are however two things to bear in mind before criticising the book too heavily.

Firstly, as I mention in my own mini-review of the book, the purpose of the book is primarily to teach DSL Tools. The examples may therefore be simplified, even to the point of being poor DSM practice, to keep them simple enough that the main focus is on the tools.

Secondly, it's often vital to the acceptance of a DSL that it generate code that looks the same as existing code. The normal pattern for moving to DSM is straight coding => components => framework => textual DSL or XML => visual DSM language. There's a nice picture of that development by Don Roberts and Ralph Johnson (see Fig 1 in the PDF link at top right here). With that history, the code to be generated tends to be pretty well refactored already -- so hopefully rather better than the code in the example!

In our experience at MetaCase of over a decade of helping people apply DSM, the best initial step is to generate the same code as their developers are currently writing by hand. That helps their developers to "get it", and removes many fears and prejudices caused by the appalling mess most fixed code generators lead to. After that, when some models have already been made, it is easy to improve the generator to produce better code. For instance, generating a subclass for each state, as Anders wants, would be a simple task in our MetaEdit+ (but IIRC considerably harder in DSL Tools, since they don't deal well with a single generator producing multiple files). Obviously, it's then much easier to change every developer's code to the new format by regenerating, rather than by sending them a memo!

Code generation is only really palatable when you never have to edit the generated code, best if you never look at it. That way, you really are raising the level of abstraction, rather than just saving some keystrokes now but risking trouble later. If you want to see some real examples of DSM -- ones that work in the real world -- take a look at the cases on the DSM Forum, particularly the Sample DSM models.