Code generation, in some form, has been around for a long time. Computer Aided Software Engineering (CASE) Tools have been around for a long time.
In more recent times another bunch of tools have come onto the market. These are usually described as Object Relational, or O/R, Mappers. Here I will describe what these are and why you should use one.
I mostly program in Visual Studio .Net. Mostly in Visual Basic but occasionally in C#. Both of these are Object Oriented languages, although some purists would argue how well they perform in this area. For example, neither of these languages support multiple inheritance. Programmers who use Eiffel, for example, will tell you that multiple inheritance is a must for any Object Oriented programming. Others will suggest that inheritance of any type is overhypped. Dan Appleman, a Visual Basic guru from long ago suggests that inheritance is the coolest feature you will never use.
My view is that inheritance is very useful, especially in form inheritance. Inheriting from multiple classes, though, is something that I don’t miss. One day I will have a go at Eiffel and maybe I will change my mind.
But all that is off the track. When you program in Visual Studio, in whatever language, you are programming in an Object Oriented environment, and it makes sense to utilise the features inherent in the framework, if they will work to your advantage.
Code generation, especially O/R mappers definitely work to your advantage. The basic premise behind these is that in an OO world it is easier to work with objects than raw data. It is also safer (see this article for reasons why.)
OK, see we should create objects, or entities, rather than program against the database. Can’t we do that without using an O/R mapper? Of course you can. But look what the O/R mapper does for you. Every database has CRUD operations – Create, Read, Update, Delete. You can write your own if you want to, and there is nothing all that difficult about doing that, but there is no point doing it if you can generate the code to do it in a matter of seconds.
But that’s not all. By setting up relations within the O/R mapper, or within the database managment system you can create the objects which span multiple tables. This way we are really dealing with useful information, not just raw data. Collections and Read-Only typed lists can be created, and the big advantage is that because the O/R mapper has been thoroughly tested, at least the reputable ones have, you are sure that the code works. Every time we write our own code we introduce the possibility of creating bugs. In this case usually from our typos, and we all make those.
Estimates I have read suggest that the data access components to the average business application can make up around 30% of the total code. So you eliminate 30% of your coding effort, 30% of the potentiality for introducing bugs, and, I also believe, that you simplify your design process.
O/R mapping is not a panacea, but I don’t find typing the most enjoyable part of software development. Anything that gives me a reliable and efficient method for removing the some of the drudgery from programming has to be a benefit, both for me and my clients.