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?

Cross posted from http://weblogs.asp.net/IanRobinson