Over the last few months I've been building DNN 3.x module for a local non-profit. I've built a couple of DNN 2.x modules, and armed with the Wrox Press DNN book, I dove in. These are some things that really stuck with me from this experience...

Page Caching
Its not obvious that your module is cached by default. Thus if you create a module that has dynamic content, it's pretty confusing to see that it works as expected when logged in as Admin or Host, but does not work when logged in as some other user (or anonymous). The caching can be changed in the module definition, or when the module is added to the page (Settings -->Page -->Advanced), but if you know your page is gonna be dynamic, then it's best to set in the module like so:

MyBase.ModuleConfiguration.CacheTime = 0

Unit Testing
I tried a bunch of things to get some unit tests to work for my Data Access Layer. In previous experience with DNN, I've found that a lot of time was spent trying to sort out the DAL (even using templates - more below). Thus adding in unit tests would be a great way to validate that the DAL is working correctly. I was a while ago now, but I tried all kinds of stuff to get it working, and eventually found a post on the DNN Forums about this. I had ended up doing something similar, and then tried to reproduce what was outlined on the thread. No luck. And some others have also tried without luck. Anyhow, I hope someone can help sort this out because it would really help all of us who are developing for DNN.

Code Smith Templates
First off, thanks to all who have worked to create the DNN Jungle Code Smith templates. I would say that they are pretty handy for getting to know the DNN provider model, and can easily be used for very simple database schemas (1 or 2 tables for your module). However, if you are dealing with 1-M or M-M relationships, or more than say 5 tables, it's more of a pain to code using the output of the templates than it is to roll your own.

For example - if I have a 1-Many relationship in the database, I want my DAL class for the "1" table to contain a typed collection of classes from the "Many" table. Trying to manually maintain this sort of relationship using a set of other "controller" and "info" objects is a real pain. It also makes the DAL model more complex to use. This in turn makes it difficult to have a team made up of various skill and experience levels.

And finally (and this is likey personal preference) - I like having a single Controller for all the 'Info' classes - makes it easier to know what you're working with, and you have to create fewer objects.

MyGeneration
More recently David Wright left a comment over on ArcDeveloper suggesting I check out MyGeneration. Turns out that AppTheory has created some DNN 3 templates for it. I have not had a chance to look at how these work, but I'm thinking we're going to start using MyGeneration (free) rather than buying into CodeSmith ($400 / developer). In the little playing I've done with MyGeneration, I think that I'll be able to create templates which more closely meet my needs outlined above.

Another thing - (this could be my inexperience with CodeSmith), but all the templates I've seen deal with one table or one database at a time (think this is related to the interaface options in CodeSmith) - I'd like to be able to select a group of tables (i.e. all the tables related to my module) and have it do all the code gen at once. From reading in the CodeSmith forums, it sounds like people run the tool once for each table, export the settings and then run it in a batch mode. This seems a little long winded to me, but if it works, it's great. However, just doing a little playing around with MyGeneration, it looks very easy to select groups of tables within the default interface.

Another interesting option is to create your own database connector - and what comes to mind for me is a geodatabase connector. That would allow us to create feature class extensions / multi-version view DAL / wrapper classes via code gen. Since this would be a big boon for us, I'll be looking at this in the coming weeks.