Code generators have been around for a long time. They have provided a significant productivity benefit to a great many developers. They speed up initial development in many categories of applications. They enable less experienced developers to build applications they couldn’t otherwise build. They sometimes can even target multiple platforms simultaneously. So, why shouldn’t they be used to build business applications? Read on to see why we think a development and run-time meta-data driven model is better for building dynamic business applications.
The fundamental challenge with Code Generators is that their goal is to generate code, not create usable business applications. Generating code creates several challenges:
- Code generators usually generate a great deal of code. The code is often complex and is hard for many developers to fully understand. The initial productivity boost can be compelling but unless the developer is quite familiar with the generation model, modifying the generated code is often quite a challenge.
- Code generators require developers for everything. Developers should be empowered to focus on what they really want to do anyway – work on the interesting and more complex challenges. Code generators that generate mountains of code and require code regenerations whenever application changes are needed require a developer to carefully manage all of that code, compile the code in a tool like Visual Studio, deploy the code to a stage/test and finally production environment. These steps should all be possible without a highly skilled developer doing them.
- Code generators bind people to a platform. The generated code that is platform specific must be modified by the developer in many instances and that in turn results in a challenge in porting code forward. For example, if you used a code gen tool to build a WinForms application and then decided to move your application to ASP.NET or Silverlight, you would have to extract your modifications from the code generator manually, migrate them, port them to the new environment, and then go forward retesting, etc.
- Regeneration limits what you can modify .In most tools, if you want to be able to regenerate an app after defining some changes, you have to be very careful about where you modify the generated code. Each code generator has a different scheme for providing areas to modify and some are certainly better than others. The fundamental issue though is that this approach can create a lot of complexity and limitation, coupled with risk that developers in a team setting will not universally follow the same standards creating situations where custom code is wiped out when the app is regenerated.
- Business Analysts and Power Users can’t participate. These days, many non-developers want to get involved in the process of creating business applications. This is most true in departmental workflow and line of business apps. For enterprise apps it is less common but a growing trend. Code generators are by definition developer centric tools. In order to empower a business user to get meaningfully involved in defining an application a code generator tool is a non-starter.
Dynamic Business Application Meta Data Driven Model So, if Code Generation is less than optimal for business application development, what is better? Our view is that using a graphical, meta-data model that doesn’t generate code to define an app and is executed directly by a run-time meta-data engine is more productive and cost effective. The idea is for that meta-data to be open, easily extensible, and portable. The run-times can then support a variety of normally incompatible environments such as Windows and Web with the same application. The meta-data environment can go from simple to complex. For business users trying to define a simple or medium complexity app, they can do everything they want with graphical tools. If no complex rules or workflows are required, the business user can directly promote an app for testing and deployment without any coding, compiling, or manual deployment work. If a developer does need to get involved for more complex apps, define the code in a highly componentized and granular way that plugs in to the rest of the environment. Developers then get the best of breed development capabilities and language of choice within Visual Studio .NET. Their output is a portable extension to the meta-data that then is consumed by the run-time environment. The end-result is that the run-time framework can actually be modified in nearly any way imaginable, but it is done with plug-ins and run-time object consumption and aggregation rather than through code generation. End result: developers can focus their energy on building world-class software and business users can contribute meaningfully to complex apps and control a great deal more in simple to medium complexity apps. Even more importantly, the long term total cost of ownership is much lower since the meta-data is portable and will migrate from one major technology platform to another over time.