This is the question that was posed on the DNN forums yesterday.

Is it just me or are data providers done wrong?

Hey all - I'm trying to understand the basic architecture of DNN and am wondering if I am off base with how I understand the data provider model to work.  From what I can tell EACH module has a specific data provider implementation in addition to the abstract dataprovider class.  Unless I'm missing something this seems really messed up - For instance I would LOVE it if DNN ran on MySql but it doesn't - so if someone wants to run a DNN site on MySQL, they would have to add MySql data providers in all modules?   If this is the case, this just seems horribly wrong - it would be MUCH better if we had the data providers centralized and then all modules would point to a generic common abstract class - so one could add/change data providers on the entire system without having to modify or add code to existing modules.  The way it stands right now, it seems like it'll take a hell of a lot of effort to get another provider simply because one would have to touch all the core modules.  Am I missing something?

Bob

Yes Bob, you're missing EntitySpaces. Well, I (Mike speaking here) wrote up a very nice and informative post letting Bob know that what he was describing was in fact EntitySpaces. It was a pretty involved post expanding on what Scott said and correcting a misconception on a subsequent post by another poster . Bob is obviously a very bright guy and asked the very question that all DNN developers should be asking. I went on to explain how our massive NUnit test suite executes against Microsoft SQL, Oracle, MySql, Microsoft Access and now VistaDB (not yet released but working). We use the same exact binary in this test suite against all of our supported databases. Imagine one code base with your modules running on all database systems. I also stated that it's too bad DNN itself doesn't run on EntitySpaces because its reach would be far wider and "would be DNN module developers" would have a very simple programming model instead of the rather clunky DNN DAL. Also, they would have at their fingertips Transactions, LINQ Support, serialization and far more customers to reach out too to make their ventures more profitable.

The above isn't my exact statement, I didn't call the DNN DAL clunky in the post and it was at least 4 times as long as the text above explaining that EntitySpaces was exactly what Bob was in fact wanting in an architecture. My post was rejected with no explanation and without even a notification, this is their right of course. But that doesn't mean I have to let this go unnoticed. We are DNN fans and we won't be silenced. It makes me wonder if any of the younger new .NET portals are paying attention here.

[UPDATE - Nov 6, 11:00 EST]
Well, a day and half after my original post and after this blog post had gotten around the horn my original post on that thread somehow appeared, and for that I say thankyou to the DNN folks. Nonetheless, this post remains. However, We extend an open invitation to the DNN core team members and founder to speak with us about blowing the doors wide open for the DotNetNuke community, we believe it is within our power to help DotNetNuke do just that.