Corner of Seven Helping Tech and People to Get Along

DNN Module Creation, Explained (part 1).

Since I haven't shown up here for a while, I should talk a little bit about what's been going on in my life. I'll keep it short.
December: Left my job in Rock Island, was in a musical at Quad City Music Guild, Found a job in Dubuque at 365Advantage, lived in a suitcase until I found an apartment, worked on mobile phone development.
January: found an apartment, continued phone development until our other two developers left, was told in a week to learn DotNetNuke module development.

So here we are.

I've had some consternation in trying to figure this framework out (I come from the Java n-tier and Ruby on Rails MVC worlds). The biggest is getting my head around WebForms. For some reason, carrying state of pages between each other seems dirty to me, compared to handling everything by referencing the entities themselves (a la REST). I've even googled it:
Turns out that's not how they do things in the DNN world.

Through some aid via the book Professional DotNetNuke Module Programming and the books author, Mitchel Sellers, I think I've slowly gotten a hang of the basics.

On the face, DNN is a CMS. Compare a default install with something like vanilla Radiant or WordPress. But most people forego that aspect of it, and use the portion of DNN that they've become known for: pluggable modules.

You would think that a system that was built to be completely modular would make it easy to build modules, right? I WISH. Maybe it's just me, but I shouldn't NEED Visual Studio, SQL Server Management Studio, and some magic to build a module. Then again, I come from Java and Ruby, where I'm not tied to an IDE. DNN Module building requires it, though.

Now that I've finished complaining, Part 2 will demonstrate how I've managed to get around this, and use the services that .NET provides (like LINQ to SQL) to make DNN Module building as painless as possible.