Iron Speed: To Generate or Not to Generate?

The Virtues of Laziness

If necessity is the mother of all invention, then laziness is a doting aunt, especially where developers are concerned.
Our desire to do as little work as possible has spawned, paradoxically, impressive feats of ingenuity.
We replaced our spaghetti-code subroutines with re-usable, elegant objects (OOP) figuring why do many times what can be done once; we abandoned our hard-coded data-layer drudgery in favor of drag-and-drop ORMs (ala Linq To Sql and Entity Framework); we even fled from manual GUI code (perish the thought!) and found refuge in the warm welcoming arms of template-driven web pages (Dynamic Data); we leverage Http Modules and fancy new Design Patterns whenever humanly possible (do I hear Inversion of Control?).
All-in-all, our laziness has paid off. Our code is more modular, maintainable and we get to use the battle cry DRY (don’t repeat yourself) when nobody’s looking.
The next evolutionary step, one might think, is code generation. Why write code at all when someone (or something) can do it for you?

Code Generation

For our purposes code generation refers to:

any tool that generates a fully-functional web application based on a set of database objects.

The generator creates web pages based on database tables and uses foreign key relationships between tables to create links between the web pages.





Iron Speed is one such code generator for ASP .NET.
The generation process involves 5 steps:

1. Select a design theme (menu above or at the side, color scheme)
2. Select the page types you require -  record display, table display, reports, emails, workflows, etc. – and select the relevant database tables or views
   
3. Select a few configuration settings (code language, Sql or stored procedures, etc)
4. Let Iron Speed generate the web pages, data and business layer code in under a minute or two.
   Each page involves 5 files:
   - an html layout file
   - settings stored as xml
   These are used to generate the other files:
   - an aspx file
   - a code behind file (page.cs for C#)
   - a code file with classes for each Iron Speed control on the page (page.Controls.cs)
   
5. Customize! (Rarely will Iron Speed guess correctly which fields you want to display.)

The last step is the most time-consuming. Customization involves two activities:

• Using the Iron Speed designer – this makes changes to the html and xml files. When you re-build the site, the code files will also change.
• Change page behavior by overriding methods in the code files in the designated sections. These changes will not be overwritten when you next build the site.

Pros and Cons

The advantages are obvious:

• Quick development time
• Rich GUI applications: paging, export to Excel etc., menu’s, reports
• Object-oriented code design
• Data layer can be configured to use either straight SQL or Stored Procedures
• Online forums for troubleshooting
• Simple if limited authentication-authorization infrastructure for forms or Active Directory-based security.

Immediate downsides include:

• Expensive – licenses are in the thousands of dollars
• Restrictive licensing policy – licenses are connected to specific users so forget about transferring a license from one team member to another even if the former has moved to Timbuktu.

But the more important disadvantages emerge only further down the road.

Iron Speed Gotchas

• Customizations made via the Designer are lost when even minor changes are made. This can be a serious setback for application maintenance of customization-heavy pages. A minor tweak becomes a start-from-scratch task.
• IronSpeed version upgrades often break code and require recoding.
• Stored procedures are overwritten, not altered, and thus will lose their permissions properties each build. The procedures are based on dynamic queries and thus you’ll need to grant permissions to the actual tables in addition to the procedures.
• GUI design is limited. Forget about moving your menus from below the logo to above – you’ll have to wade through pages of “theme” code – partly in XSL – which is littered with misleading obsolete code files. You may resort to very complex customizations and workarounds that defeat the purpose of code generation. Good luck!
  ”Why, o why,” your users will whine, '”can’t you just move the button to the other side?”
• Simultaneous development is a major headache. The designer makes seemingly random changes that make code merges a nightmare if not practically impossible. The end result: features that “disappear” after a merge.
• Users with minimal privileges may have empty table columns where buttons and values have been hidden. “Why can’t you just hide the damn table column?” is another familiar user complaint.

Conclusions

For small applications that follow the database table structure closely and require little updating, Iron Speed is a pleasure.
However, when it comes to a monster application delivered to demanding users and implemented by a multi-member Agile development team over multiple phases – think twice. The time you save on your first iteration will be devoured by your second, third and so on.
You may want to roll your own site or even tinker with Dynamic Data, which, being a template infrastructure as opposed to code generator, will offer the flexibility and predictability you seek, at the cost of fewer bells and whistles out the box.
Bottom line: laziness has a dark side too.