Code Generators in the Enterprise: Where They Shine. RAD Codegen from a practitioner’s perspective with timeless lessons.
Dialogue
PM: We need the customer portal stood up fast. The board wants a demo next week.
Lead dev: We can either hand write data access, DTOs, services and the same five patterns yet again or let a code generator do the boring parts and we focus on the weird bits that matter.
PM: Generators scare me. I do not want magic I cannot debug.
Lead dev: No magic. Templates plus metadata. Visual Studio already does it with typed DataSets. Rails does it with scaffold. We keep our rules in plain text templates. If we do not like the result we change the template and run it again.
Evidence
In the last two projects we used CodeSmith and MyGeneration to spit out data access layers, unit test shells and service proxies. For a database of 30 tables the generator produced about 120 classes in minutes. That saved our team a full week of typing and cut copy paste bugs to almost zero.
This is not a fringe idea. Visual Studio 2005 creates typed DataSets and web service proxies from XSD and WSDL. LLBLGen Pro and NHibernate templates pull metadata from your schema and create mappers. On the Java side you get proxies from Axis and rules from XDoclet. Rails scaffold gives you a running CRUD screen before lunch. That is code generation already mainstream in our tools.
Where does it shine
– CRUD by the pound: repositories, DTOs, validators, stored procedure wrappers.
– Service glue: contract code from WSDL and XSD, message mappers, config entries.
– Tests and stubs: empty tests with arrange act assert blocks that reference the right types so the team only fills assertions.
– UI scaffolding: simple master detail pages that respect naming conventions and security attributes.
The wins are not just speed. Consistency is the big prize. Same null checks, same transaction boundaries, same naming. New hires learn faster because every project looks familiar. Review becomes about behavior not style wars.
How we run it in the real world
Start from real metadata. Pull from the database schema, XSD or WSDL. Avoid side spreadsheets that drift. If the source of truth is your schema, drive from that. For models use DSL Tools if you are brave or a simple XML file everyone can read.
Never hand edit generated files. Put hand made logic in partial classes on .NET or in separate subclasses and helpers on Java. Treat generated code as disposable. When the template changes, regenerate and move on.
Keep templates boring and small. A template should do one thing. Put a banner at the top with template version, source snapshot and a do not edit warning. Store templates next to the code in source control so pull equals build.
Automate the run. Wire the generator into NAnt or MSBuild. Have CruiseControl.NET call it on every commit. Either check in generated code for easy diffs or regenerate on the server. Pick one and stick to it so builds are repeatable.
Expose clear settings. Make it trivial to map table names to class names, pick a base class, plug in a namespace. The less hand editing after generation the better the return.
Scaffold to learn then replace. For Rails, a scaffold gets you moving. Then replace the views and controllers with what users really need. Same story in .NET with templates that spit out ASPX pages. Use scaffolds as training wheels not the final ride.
Risks
Lock in to a tool: If your stack depends on a paid generator, budget the license and keep a plan B. Favor template engines that are plain text and scriptable.
Template rot: When the schema moves and the template does not, you get pain. Appoint an owner. Treat templates like production code with reviews and tests that build a small sample project.
Merge pain: Hand edits in generated code lead to tears. Solve this with partial classes and strict rules. If someone edits a generated file, the build should fail loudly.
Security holes: A naive scaffold can expose columns or miss parameterization and invite SQL injection. Bake parameterized queries, encoding and authorization checks into the templates so the safe choice is the default.
Performance surprises: Generators can produce chatty data access or heavy mappers. Profile early. If a rule hurts performance, move it out of the template into a hand tuned hotspot.
False confidence: Teams can ship fast and think design is done. A generator only copies your rules. If the rule is wrong, you now have the wrong thing in fifty places. Keep your head on.
Graceful exit
Use code generation to sprint through the repetitive layer, then slow down. When the domain gets weird, stop generating that part. Freeze the template, check in the last good output and treat it as hand code from then on.
A simple test helps. If you can say the rule in one sentence that fits on a template comment, it is a good candidate. If you need a whiteboard and a debate, keep that logic hand made and reviewed.
There is no medal for purity. The sweet spot is this. Let generators grind the grunt work. Let people make the calls that need taste and context. With Visual Studio 2005, Rails, CodeSmith and friends we already have the gear. Use it with care and your team buys back time for the features users actually notice.