New Community Website

Ordinarily, you'd be at the right spot, but we've recently launched a brand new community website... For the community, by the community.

Yay... Take Me to the Community!

The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact .

The use of the Community Blog is covered by our Community Blog Guidelines - please read before commenting or posting.

Juking With Data Providers

There is one other item of particular interest to some that came out of our core team chat.  That item is regarding the scope of what I'll call the “Core DataProvider” for lack of a well defined term.  Each private assembly requires a DataProvider for each supported DBMS.  The “Core DataProvider” is the one that facilitates the guts of DotNetNuke.... rather than, say, a PA.  The term could also encompass a particular DBMS implementation (e.g. “mySQL Core DataProvider“) or the abstract contract for any DBMS implementation.  Enough with definitions.

There has been considerable discussion within the core team (and without) about building DotNetNuke “lean”.  By that I mean abstracting wherever possible to create looser coupling, thereby allowing other developers to extend DotNetNuke in ways which will not necessarily be impacted by upgrading (e.g. PA's).  One simple way to initiate a change like this is to take all the current “default modules” and build them as their own PA's.  This is a good idea in concept.  But it has complications.

For whatever items will continue to “ship” with DotNetNuke (including default modules) a 3rd party developer of a DBMS DataProvider would have to provide support.  The more instances of actual DataProvider components are separated... the greater the support responsibility and complexity for any 3rd party provider.  However, the fewer the instances of actual DataProvider components... the greater the likelihood of frequent change and thus increased support responsibility and complexity for any 3rd party provider.  Hmmmm.... a balancing act?  Third party module developers will always have their own DataProviders and support RDBMS's based on market demand for their tools.  But the conundrum for encouraging and supporting 3rd parties to implement the DotNetNuke Core (!) on different DBMS platforms is different.

A solution approach which is on the table is to separate the current default modules from the rest of the core into a single PA.  This would provide a compromise between flexibility for continued development and support requirements for “Core DataProvider” vendors.  So what is now one “Core DataProvider” would become two.  Both shipped with DNN.  But the business logic required for the current default modules would no longer be embedded in the DataProvider which should rightly contain architectural functionality.  And improvements to the default module collection could proceed on a separate track from the true core.

This is the current train of thought.  But, as I stated earlier... it is tabled until Beta II is released (as is scope for 2.1).  Until Beta II is out the door we won't even discuss... juking with DataProviders.

re: Juking With DataProviders 2/10/2004 7:12 PM bertcord

I think each PA should be separated into its own separate PA. Yes I agree that the has its complications but I also feel that its benefits outweigh the complications. I have seen numerous posts on how to update existing modules but many users do not want to perform the modifications as it touches the core. Separating these modules into there own PA will enable many more users to become involved in the project. IF someone wants to improve the HTML module they do it and submit the PA. NO need to worry about recompiling the module PA. This would be a good place for new people to get included and the core team can just work on the core

My .02

re: Juking With DataProviders 2/11/2004 2:18 AM iwonder

I agree with Bert. The standard modules are great starts, but simply cannot provide for every littl nuance a developer requires for a client. Even if Core decides not to do it, it is already being done, why not make it official? Focus on the framework, and keep it private.

re: Juking With DataProviders 2/11/2004 11:03 AM miket

I also think they should be in separate PAs, if only to allow as lean a system as possible. Nobody uses ALL of the default PAs. There should be an uninstall process for ones that aren't necessary. That will also allow for complete replacement of modules that have improved over the default ones. No duplication.

But beyond that, I also think that the admin modules should be pulled out into their own PAs as well, why not allow modification and improvement to the host and admin modules without effecting the core.

re: Juking With DataProviders 2/11/2004 11:57 AM Jan Olsmar

Make one separate provider for the standard modules.
In the long run ther will be enough with providers and dll's. If someone will change a standard module its easy to copy parts and make a new seperate one. Maybee the design for multilanguage solution have impact on the question to. If too many dll's it will be hard to maintane the application. With 40 modules it will bee 82 dlls with one database. 166 with 3!
Jan O

re: Juking With DataProviders 2/12/2004 2:35 PM Jonathan Moore

I agree,
for example I'd like to change a lot of the default modules to avoid excessive postbacks/roundtripping eg when expanding a faq item, since all version4+ browsers can handle the javascript to do this.

Now I could take a copy of each default module and release as a new module or PA and disable use of the standard module within my site, that way I could take updates of the core without breaking my mods, but would be better to submit changes to core mods.

re: Juking With DataProviders 2/12/2004 11:15 PM Shawn Mehaffie

I definately think all the core modules should be made into seperate PA's. I am also for the core administration modules being made into seperate PA's. This would allow seperate modules to be updated without updating the core.

Plus, with certain modules it will allow more flexibility. For instance, I could write a customized login and registraiton page that uses a company authen database, while at the same time also store the user information in the DNN user database to maintian referential integrity, and still use the standard DNN roles.

S. Shawn Mehaffie.

P.S. Make the tags for the Privacy Statement and Terms of Use definable for each portal. This is the only place where text is hard coded and by storing the text in the database the portal can easily be used for web-sites in other lanquages.

re: Juking With DataProviders 2/12/2004 11:18 PM Shawn Mehaffie

Another advantage of seperating all the core modules to PA's is that the core dll would be smaller and each module DLL would be smaller. That means that the memory usage would be better managed, since only the core modules on the page would be loaded into memory. Plus, the smaller the assemblies the faster they compile and run.

re: Juking With DataProviders 3/12/2004 3:27 PM Chris Kleszynski

Separating admin modules from the core is excellent idea. It would make many admin's life easier.
Mine registration is for example heavily modified and localised - upgrade is becoming a major undertaking.
I yearn to move to 2.0 but fear the problems involved in that move and subsequent (frequent) core changes and upgrades.

re:Juking With DataProviders 4/10/2005 6:44 AM 红外热像仪

^_^,Pretty Good!


There are currently no comments, be the first to post one.

Comment Form

Only registered users may post comments.


Aderson Oliveira (22)
Alec Whittington (11)
Alessandra Davies (3)
Alex Shirley (10)
Andrew Hoefling (3)
Andrew Nurse (30)
Andy Tryba (1)
Anthony Glenwright (5)
Antonio Chagoury (28)
Ash Prasad (37)
Ben Schmidt (1)
Benjamin Hermann (25)
Benoit Sarton (9)
Beth Firebaugh (12)
Bill Walker (36)
Bob Kruger (5)
Bogdan Litescu (1)
Brian Dukes (2)
Brice Snow (1)
Bruce Chapman (20)
Bryan Andrews (1)
cathal connolly (55)
Charles Nurse (163)
Chris Hammond (213)
Chris Paterra (55)
Clint Patterson (108)
Cuong Dang (21)
Daniel Bartholomew (2)
Daniel Mettler (181)
Daniel Valadas (48)
Dave Buckner (2)
David Poindexter (12)
David Rodriguez (3)
Dennis Shiao (1)
Doug Howell (11)
Erik van Ballegoij (30)
Ernst Peter Tamminga (80)
Francisco Perez Andres (17)
Geoff Barlow (12)
George Alatrash (12)
Gifford Watkins (3)
Gilles Le Pigocher (3)
Ian Robinson (7)
Israel Martinez (17)
Jan Blomquist (2)
Jan Jonas (3)
Jaspreet Bhatia (1)
Jenni Merrifield (6)
Joe Brinkman (274)
John Mitchell (1)
Jon Henning (14)
Jonathan Sheely (4)
Jordan Coopersmith (1)
Joseph Craig (2)
Kan Ma (1)
Keivan Beigi (3)
Kelly Ford (4)
Ken Grierson (10)
Kevin Schreiner (6)
Leigh Pointer (31)
Lorraine Young (60)
Malik Khan (1)
Matt Rutledge (2)
Matthias Schlomann (16)
Mauricio Márquez (5)
Michael Doxsey (7)
Michael Tobisch (3)
Michael Washington (202)
Miguel Gatmaytan (3)
Mike Horton (19)
Mitchel Sellers (40)
Nathan Rover (3)
Navin V Nagiah (14)
Néstor Sánchez (31)
Nik Kalyani (14)
Oliver Hine (1)
Patricio F. Salinas (1)
Patrick Ryan (1)
Peter Donker (54)
Philip Beadle (135)
Philipp Becker (4)
Richard Dumas (22)
Robert J Collins (5)
Roger Selwyn (8)
Ruben Lopez (1)
Ryan Martinez (1)
Sacha Trauwaen (1)
Salar Golestanian (4)
Sanjay Mehrotra (9)
Scott McCulloch (1)
Scott Schlesier (11)
Scott Wilkinson (3)
Scott Willhite (97)
Sebastian Leupold (80)
Shaun Walker (237)
Shawn Mehaffie (17)
Stefan Cullmann (12)
Stefan Kamphuis (12)
Steve Fabian (31)
Steven Fisher (1)
Tony Henrich (3)
Torsten Weggen (3)
Tycho de Waard (4)
Vicenç Masanas (27)
Vincent Nguyen (3)
Vitaly Kozadayev (6)
Will Morgenweck (40)
Will Strohl (180)
William Severance (5)
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out