This is posted in the MyGeneration forums:
http://www.mygenerationsoftware.com/phpbb2/viewtopic.php?t=770&highlight=

Many people have been asking for templates to generate Microsoft's Data Access Application Blocks (DAAB). My contention, having done projects with both DAAB and dOOdads, is that you should use dOOdads.

Still, I considered writing the templates just because it seemed there was enough interest, and I already have a base set of templates from my previous project as a starting point. However, after reconsidering, I thought it would be more useful to demonstrate how easy it is to plug dOOdads in place of Microsoft's DAAB.

My web site uses the Portal Starter Kit from www.asp.net, because it was easier than building an entire site from scratch. And thanks to 3D, I actually had a reason to go in and modify my web site's code. Since I had not replaced the DAAB in the portal with dOOdads, I decided I would go ahead and build this example.

You can download the source code from here:
http://www.noonanconsultinginc.com/miscfiles/PortalCSVS.zip

Installation Instructions:

1. Download and install the C# ASP.NET Portal Starter Kit from www.asp.net, following their instructions. Make sure your system meets their requirements.
   
2. Unzip the PortalCSVS.zip file over top of the starter kit. The default path is C:\Program Files\ASP.NET Starter Kits\ASP.NET Portal (CSVS).
   
3. Open the solution in VS.NET 2003, and add the C# dOOdads project.
   
4. Run the dOOdads.sql script against your Portal database in SQL Server.
   
5. You should be good to go!
   

1. All data access code now uses dOOdads. The conversion took approximately 3 hours.
   
2. I did reuse some code, but not much. MS saw fit to embed some business logic in the stored procs (which is not unusual). dOOdads easily adapted to this using LoadFromSql. There may be more embedded business logic that I missed. Trust, but verify...
   
3. In most cases, custom stored procs were replaced with dOOdad Query() operations. I like this approach because it saves from having to bulk up your database with custom stored procs. Sometimes it is necessary, of course, but I think this is cleaner.
   
4. DataReaders were replaced with the dOOdad MoveNext() functionality.
   
5. Note the use of the UI friendly "s_" properties, to avoid having to check for null database values.
   

1. It probably doesn't run bug free, as I didn't have time to test all of it. Consider this a first-cut, and a how-to.
   
2. No optimizations were performed. Sometimes I made two database calls when only one was necessary (particularly on some of the delete operations). And there are some optimizations that could be done with dOOdads to Microsoft's code.
   
3. dOOdads have more capabilities than are shown in this example. There aren't really any transactions to speak of. And I didn't bother creating dOOdads based on views.