In response to a large flame-fest/discussion on the merits of code generation and object/relational mapping, I posted the following in the ASP.NET architecture forums:
First of all, what are the problems that these techniques attempt to solve (feel free to add to this if I've missed anything)?
- Code generation is a solution to the drudgery of writing repetitive code. At it's most basic level, code gen takes the form of default class templates in VS (so you don't have to write class and namespace declarations for every class, or hook up Page_Load methods for every aspx code-behind file). Using a templating tool like codesmith allows you to take this a *lot* further, by generating strongly typed collections (this particular template will be invalidated in 2.0), and even generating entire DALs and webforms based on a database structure. We all use code generation in some way, unless we're writing our applications entirely in Notepad.
- O/R Mapping is an attempt to solve the problem that comes about when we have a nice object-oriented system that needs to be persisted to an efficient relational data store. The goal is to be able to write object-oriented persistence code for our system. Nothing more, nothing less.
So why do we end up having conversations about "O/R mapping vs. Code Generation", when they're not even really attempting to solve the same problem. These techniques are not mutually exclusive, indeed O/R Mapping is a type of code generator almost by definition; It takes an object and generates SQL code based on the mappings. Most commercial O/R mappers integrate code generation into the whole mapping process, generating objects and mapping files for you based on the database schema. They're totally complementary techniques, people.
That said, let it be known that I have used an O/R mapper in almost *all* the projects I've worked on in the last year and a half (since I un-wittingly wrote my own simple O/R mapper before I even knew what they were). The one exception was a job application system I built almost a year ago. We had an extremely tight deadline, and so I looked to Frans' original free version of llblgen (which was not an O/R mapper at all). It seemed like a great solution at the time, since I could point the application at my database, and have llblgen generate the *entire* DAL of my application, including stored procedures, objects, and persistence code. However, while I may have gained initially, I still had a large number of stored procedures and c-sharp code files that had to be actively maintained. And once I'd customized the generated code according to the needs of the client I had a huge maintenance problem on my hands. This is something that an O/R mapper greatly reduces (not entirely, though).
Based on my own personal experiences (and yours may differ), I think that code generation is something that we all would be stupid *not* to use. However, if you think you can simply go ahead and generate an entire layer or two of your application, be prepared to maintain all that code as if you'd written it by hand in the first place. Once you initially generate your code, it becomes difficult to add in your own custom stuff without running the risk of overwriting it when you have to change your database structure due to conditions un-foreseen at the start of your project. That said, it'll be interesting to see what happens on the code gen front once Whidbey goes final and partial classes come into play.