Products

Solutions

Resources

Partners

Community

Blog

About

QA

Ideas Test

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!

Welcome to the DNN Community Forums, your preferred source of online community support for all things related to DNN.
In order to participate you must be a registered DNNizen

HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0Is it just me or are data providers done wrong?Is it just me or are data providers done wrong?
Previous
 
Next
New Post
10/10/2006 10:30 PM
 

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

 
New Post
10/11/2006 2:03 PM
 


Michael Washington
http://ADefWebserver.com
www.ADefHelpDesk.com
A Free Open Source DotNetNuke Help Desk Module
 
New Post
11/3/2006 11:51 AM
 

Bob,

I think you are right ON base.  There is lot done to separate and abstract the data access.  That works great.  It does add complexity, but with templates and code generators it really isn't all that hard.

I don't see how Michael Washington's description of the DAL and DAL+ explain how it is possible to have modules that don't have separate code for each dataprovider.  Granted that code will not have to be sprinkled throughout the BLL code.  But at some point it eventually calls a stored procedure.  The two big problems are:

1.  What happens with databases that don't support stored procedures?

2.  You have to write those stored procedures for each provider for your specific module? 

so if I want to use an oracle provider then every module I use has to come with an install, that will create the tables and stored procedures necessary to add update, get... the data for that module. 

To really make it dataprovider swappable then the install would have to take some sort of generic stored procedure definitions and then the provider would translate those into the form required for it's mother database.  Then the modules don't need to know anything about the database.  All they need to know is what the dataprovider needs to get its job (of talking to the database) done.

Then ya really got somethin.

I'm with you Bob.

mj 

 


Michael Jackson
Brillnat.com
Custom module development
Database access tokenized HTML modules
 
New Post
11/4/2006 8:11 AM
 
I think this might work well for simple or small modules, but I am focusing on large DNN installations and making sure my modules are scalable. With scalabilty I think you have to move some of the logic into the DB - it would just be too inefficient in the BL -

An example: In my UserGroups module, I want to get a random module for a Featured Group page. If was using the generic approach youare proposing then I would call my generic CRUD procs and do the get random in the BL, but for scaleabilty I would actually make do the random lookup in the the stored proc. This then causes problems when you want to move to a different DB (not all functions supported perhaps).

So, while I think this approach would work for simple modules, it would not work for more complex, high-throughput modules.


Entrepreneur

PokerDIY Tournament Manager - PokerDIY Tournament Manager<
PokerDIY Game Finder - Mobile Apps powered by DNN
PokerDIY - Connecting Poker Players

 
New Post
11/4/2006 8:21 AM
 
rsriley wrote

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. 

see:

Converting the DotNetNuke® Survey module to use the DAL+ (in VB and C#)



Michael Washington
http://ADefWebserver.com
www.ADefHelpDesk.com
A Free Open Source DotNetNuke Help Desk Module
 
Previous
 
Next
HomeHomeArchived Discus...Archived Discus...Developing Under Previous Versions of .NETDeveloping Under Previous Versions of .NETASP.Net 2.0ASP.Net 2.0Is it just me or are data providers done wrong?Is it just me or are data providers done wrong?


These Forums are dedicated to discussion of DNN Platform and Evoq Solutions.

For the benefit of the community and to protect the integrity of the ecosystem, please observe the following posting guidelines:

  1. No Advertising. This includes promotion of commercial and non-commercial products or services which are not directly related to DNN.
  2. No vendor trolling / poaching. If someone posts about a vendor issue, allow the vendor or other customers to respond. Any post that looks like trolling / poaching will be removed.
  3. Discussion or promotion of DNN Platform product releases under a different brand name are strictly prohibited.
  4. No Flaming or Trolling.
  5. No Profanity, Racism, or Prejudice.
  6. Site Moderators have the final word on approving / removing a thread or post or comment.
  7. English language posting only, please.
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out
What is Liquid Content?
Find Out