irob's blog.

DotNetNuke Architecture Diagram

This post is overdue. I wanted to use this image in my slide deck for a presentation I gave last month at the Bloomington, IL .NET user group, but...it really detracts from the look & feel of the presentation as a whole makes my eyes bleed when I look at it. So anyway...I have a friend in the business of making things look good, so I'll share the wealth.

Original:

New:

There's no excuses for using the old version anymore. Thanks Dang!

Bucking Convention: Crazy Data Access in DotNetNuke

The current provider model in DotNetNuke is very flexible, but with that flexibility comes development overhead. Over the past few months I've started thinking about how much time I spend simply on [easy, repetitive] data access tasks, and its a little depressing.

I'm at the DotNetNuke OpenForce conference right now, and today I went to Jim Bonnie's presentation on data access layers in DNN. He likes to use SubSonic instead of doing everything manually. He presented NHibernate, Entity Framework, Linq to SQL, and many others as options for your data access layer. The bottom line of the presentation is that there are a lot of time saving solutions out there, and that we should probably just pick one we like and go with it.

Awesome. Let's do it.

But... we've been talking about this at the office for awhile, and there are a couple of things that I (as a commercial module developer) am not quite comfortable with yet. I have a lot of questions. Please let me know what you think. If you're at OpenForce, track me down because I'd love to talk about it.

Dependencies

If we want to create a module with any of these data access layer solutions do I have to include any new assemblies with my project? How many support issues will surface because someone else has a different version of it? How does the inclusion of the assembly impact the file size of the module package? Can the customer still upload this to a DNN site?

{databaseOwner} and {objectQualifier}

Does said solution support {databaseOwner} and {objectQualifier}. I know people use this stuff, but how many?

Provider Model

Who uses an Oracle or MySQL provider? Would they want to buy my module? Do I care? Is it really such a horrible thing to just flat out not support this because it's not worth the trouble? Is this a piece of information I can/should share

Big Picture

Is it appropriate to explain the lack of support for a particular nitty-gritty feature in pre-sale product documentation? How many customers would read it and know what it means? Can I live with the fact that some people might not realize the module won't work, so they effectively get a broken product?

How many people are not going to be able to use my module because of the decisions I made? How many people are going to request support because of issues that arise based on the decisions I made? Am I going to save development time, only to add that time back on in the form of support because of the decisions I made?

Signs your DNN Module Development skills could use some sharpening

1. Your latest DNN module utilizes in-line CSS like it was going out of style.
2. You frequently need to release new versions due to changes that consist solely of updates to hard coded strings in your code-behind.
3. Every time you implement your modules as part of a new solution, you spend the first few days just getting them to display correctly in the new skin
4. You FTP into the production DNN site to upgrade your module.
5. You spend more than 30 seconds packaging a new version of your module
6. When you get a SQL script from source control you open up your favorite file comparison utility to see what’s changed so that you can run only those changes.
7. You’ve been curious, for the last two years, about how to use the DNN UrlControl, but you never have the source readily available, so you still don’t know.
8. The last time you upgraded your production environment you were up until 4AM trying to piece together outdated versions of your database.
9. When creating your latest DNN module, you opened up the first DNN module you ever created to grab that same piece of code that you always grab when creating a new module.