Home » DotNetNuke - Module Development » DotNetNuke – Data Access Layer Alternative

DotNetNuke – Data Access Layer Alternative

land-0107 Now that I’ve explained the standard way of creating a Data Access Layer (DAL) for DotNetNuke, we can address the alternative method of providing this same functionality.

You see, the only reason for creating the DataProvider abstract class and the SqlDataProvider implementation class is so that alternative data providers can be created. Originally, this was so that DotNetNuke could be supported on either MS-SQL or MS-Access databases. MS-Access is no longer supported by the DotNetNuke core, but there are still providers available for MySQL, Oracle, and probably a few others.

So if you are writing a module, or a set of modules, and they are intended to run on any DotNetNuke installation, you’ll want to follow the provider pattern I’ve laid out in the last several posts.

However, if you are writing a module that only needs to run under one installation, you can forget about the provider model. Use CodeSmith to create your stored procedures. But once you have those, you can use the standard DataSet and DataAdapters that are available to us in ASP.NET 2.0 or higher.

Of course, those of you who have been following along and have created a module using the provider module for a module that doesn’t need the provider model are thinking, “Now he tells me!”

So, in my defense, I will only say that I think it makes sense to learn how to do something “right” prior to “breaking the rules.” So if you are writing your first module in DNN, I would strongly recommend that you use the provider module just so you know how it is done and can gauge the level of complexity. My personal experience has been that most of the work in creating a module is above the DAL and that the extra work required to implement a provider model, once you are familiar with it, is trivial.

You’ll have to do it at least once so that you can make your own judgment call.


Other post in DotNetNuke - Module Development

Like this Article? Subscribe to get every article sent to your email.

Related Post

  • DotNetNuke Modules – Creating Base ModulesDotNetNuke Modules – Creating Base Modules Now that we have DotNetNuke installed into Visual Studio we can go ahead and create our first modules. Actually, creating the modules is pretty simple. But it is even easier to do it […]
  • DotNetNuke Modules – Data Access LayerDotNetNuke Modules – Data Access Layer Now that we've created our stored procedures, we are going to use some of the other CodeSmith templates to generate our data access layer (DAL).Keep in mind that the templates you are […]
  • DotNetNuke – Modules – Portal Specific ModulesDotNetNuke – Modules – Portal Specific Modules Many of you won't care too much about creating Portal Specific Modules because you'll be creating modules for an environment that only has one portal. However, if you are creating a […]
  • DotNetNuke Modules – Foundational ConceptsDotNetNuke Modules – Foundational Concepts There are two design patterns that DotNetNuke relies on heavily, not just in the core code, but in any module you might develop.The first is a three tiered architecture, or more […]
  • DotNetNuke Modules – Install DNN into VS 2008DotNetNuke Modules – Install DNN into VS 2008 Today, we will install DotNetNuke into Visual Studio so that we can create our first module. So fire up Visual Studio, and let's get going.I'll be using Visual Studio 2008 to walk […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer. His commitment to quality through test driven development, vast knowledge of C#, HTML, CSS and JavaScript as well as his ability to mentor younger programmers and his passion for Agile/Scrum as defined by the Agile Manifesto and the Scrum Alliance will certainly be an asset to your organization.