Have you tried Data Access Application Blocks? We use them and we only need 1 line of code to read the database.
SqlHelper.ExecuteReader(strConnTxt, CommandType.Text, strSql);
Alternatively, you can use SqlHelper.ExecuteDataset.
We also use Code Generation software that builds all the CRUD methods automatically.
I can understand what would bring you to using a code generator, but the examples I have seen in practice are not good. I think code generators show there is something fundamentally wrong with the language/framework.
Here is what I meant: When a commercial application becomes popular to generate large amounts of code to do a small amount of work, like some CRUD, I personally feel that shows a flaw in the fundamental way the language works. The language should either be able to offer you a better way of doing it yourself, or writing a small framework for yourself. If neither of these are viable options, I would consider that a serious knock against the language.
Here's the problem with what you said -- the word "code". It's not defined. In any kind of large environment, my application uses all kinds of compiled code. So what if I push a button or flick a switch to use another hunk of code that I don't have to write or test? Is using System.Io somehow "better" than say, having an automated macro that generates IO based on some user preference?
Yes -- I would agree that if I have to write and maintain a large amount of code to do easy stuff we've got a problem somewhere. But if my platform is powerful enough to allow me to use multiple Data Access paradigms without any work on my part? Who cares if when I flip the switch the code is generated and compiled or if it was generated and compiled last week or last year?
Take a look at something like CodeSmith. Here's a tool that uses .NET to write programs for .NET. Now yes, you can generate a lot of code that way -- if you want to look at it like that. You can also go and get open source libraries and templates that will generate tested, proven, full-featured libraries based on your particular situation. Isn't that a much better thing than simply having one paradigm that everybody has to shoe-horn their work into?
Obviously, I am biased by what I have seen in practice. I also dislike a lot of 'magic', or things I don't understand and have control over being tightly integrated with my code.
What I think I see happening over the past few years is a lot of authors and researchers developing code generation templates as part of their work. So instead of the guy who's got the book telling you to make 7-tier, multi-phasic, distributed apps, you got the guy, a website, a following, and a set of templates and wizards that make this thing for you.
I'm not crazy about that at all, but I think it is having the effect of evolving the code generation community. I'm seeing a lot more people who want to "program the programming" Most, of course, create monsters. But it only takes one good set of easily-used and rock-solid templates to create real value for everybody. So in the old days, there was 5-10 CASE tools and they all sucked, now there's more like 500 template authors, and 10-15 are pretty good. In my opinion, that's a good trend, but the genre of "code generation" still has a well-deserved negative connotation.