Some people look at code generators as a fast way to build an application skeleton. Then you put it away and start changing the generated code. You can never again regenerate the code because you would loose all changes. After the initial phase, the code generator is useless and everything must be done "by hand". That's the wrong way to look at it.

Code generation goes hand-in-hand with code regeneration

You start by interviewing the customer that has a very slight idea of what he wants. During the conversation, he becomes more aware of what he needs. When you show a prototype, he starts to find out he forgot a lot of features that make a lot of sense. But after he puts the application in production, he will discover that he needs... you name it, you know the story. You might say that this example is almost a worst case scenario but it happens all the time. Even the best planned application will need maintenance and I mean RFC (Request For Changes) not database maintenance. That's the starting point for the need of code generation.

The value of a code generator isn't so much in getting the job done faster in the development phase, but to spend much less time in the maintenance phase. By time I mean the analysis time, coding time, testing time and corrections time.

That was a problem in some languages. Since .NET 2.0 this no longer a problem in C# or VB because Microsoft introduced the partial class concept. You know partial classes from Windows Forms: the Visual Studio designer generates a .Designer class that you can't touch because VS will regenerate it whenever it needs to. All your code must go in the other part of the class. A partial class can be spread across multiple files: 3, 4, I really don't know if there is a limit.

Code generators do just like VS: they generate a partial class with 2 files. One of them is regenerated whenever you tell the code generator to. The other is generated only the first time or rather, isn't generated if it already exists. If you really need to check what the code gen is generating for this file, just rename the file and merge your changes later.

This is only part of the question. In OOPS you can always use base classes and derived classes. The code generator makes the base classes and you use derived classes where you customize the class to fit your needs. Code generators can use one or the other approach or even both.

Let's take the theater play "Developer's life is hard" in three-act:

1. Make a simple and standalone application with no authorization or business rules.
2. Add a few properties to a lot of objects.
3. Change it to a very sophisticated application with configurable authorization roles, plenty of business rules, but also auditing, optimistic concurrency, etc

In act 1 your O/RM code generator can save you a lot of typing. O/RM means Object-relational mapping and refers to getting you objects (properties, datatypes and maybe relations) from database tables. Take great care with this approach because one is driven to think that each table is an object and vv. but most of the time that isn't true. That's why they coined the expression Object-relational impedance mismatch. A table hosts several objects and an object can use data of several tables. This discussion is besides the point so we will end it right here. The point is O/RM allows you to fill a property grid with "point and click". The code generator takes the property grids and generates the classes with properties and basic methods. Well not so basic as you seldom need more than what's generated. Remember this is a simple application with no authorization nor validation. Summarizing: code gen gives you Business Layer and Data Access Layer. Some tools also generate the Stored Procedure code while others do everything in the DAL using parametrized queries. Anyway this is all done for free. Depending on the sophistication of the tool, you might need to adjust the SQL statements. Very sophisticated tools also support a "hands off" change of the database provider, say SQL Server to Oracle. That's a nice ending for act 1.

In act 2 your code gen tool not only saves you a lot of typig, but saves your code a lot of bugs. You are required to edit a lot of files, inserting small pieces of code in lots of places, even in the middle of existing statements. That's a nightmare for programmers and a maternity ward for bugs. Using a O/RM code generator you just point, click and regenerate. All the right pieces fall into the right places. Your PM will love you because he can send the invoice to the customer right away.

Act 3 is the "piéce de resistance" as french say because in no way code gen could help you, unless you use CSLA. To be honest, this act intends to show the features of CSLA. The hard piece is the authorization and business rules. So let's start with the easy part.

A sophisticated code gen tool can handle the generation of auditing, optimistic concurrency and soft delete, provided the database tables have the appropriate columns. This can be added at any time. As you know from act 2, every piece will fall into the right place. Again it would be a hard job to add these features to an existing application by hand coding.

CSLA 4 has a nice modular and flexible system of rules: business/validation rules and authorization rules. You write your rule (no, you can't code gen the rule), tell the code gen tool what rules to use for each object or property and that's it. Of course you have to click on the generate button.

I don't believe code generating the rule is such a good idea because the code generation tool ends up offering only a small set of possibilities. Besides there is no value in generating the rule in each class file. It's much better to offer a good library of reusable rules or let the programmer do some work and make his own rule library (after all programmers are supposed to type at least some code).

This gives you an idea where CslaGenFork is headed in respect to the rules subject.

In act 3 CslaGenFork can take advantage of CSLA's modular and flexible system of reusable rules and make all the pieces fall into the right places.