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

DotNetNuke Modules – Data Access Layer

ppl-body-087 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 going to be using were originally meant to be used on DotNetNuke 3.x. They did a great job of creating the code we needed. But as the DataSet construct matured and Generics were introduced, the whole idea of using Info classes and ArrayList went the way of the dinosaur. So there will be some tweaking we will need to do.

For now, fire up your CodeSmith program.

The first code wizard we want to run is the C# Data Provider. Double-click that and select all of the tables that are a part of your module. This wizard will generate all of the abstract classes you will be using to access your data. Make sure you set the ObjectQualifier to the qualifier you’ve been using for your stored procedures. Copy the abstract methods out of the code windows and paste this code into the DataProvider class that the module creation wizard put in your app_code/moduleName directory when you created the module in Visual Studio. You’ll want to remove the sample abstract methods that the module creation wizard put in there and replace them with the ones the CodeSmith wizard just created for you.

Next, you’ll want to run the “C# SqlDataProvider” wizard. This will create the bulk of the code for the methods that we will use to actually retrieve the data from the database. You will run this wizard on all of your tables like you did for the abstract methods. Again, don’t forget the object qualifier.

Finally, you’ll want to run the “C# BLL Controller Class” wizard. You’ll need to run this for each table that your module needs to access. The result will be a separate class for each table. And, at the risk of sounding like a broken record, don’t forget the object qualifier.

DO NOT run the “C# BLL Info Class” wizard. We will be using DataTables and DataRows in our module so the info code will not be used.

In our next DotNetNuke module post, we’ll set up our DataTables.


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 – Data Access Layer AlternativeDotNetNuke – Data Access Layer Alternative 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 […]
  • DotNetNuke – Make Your Module SearchableDotNetNuke – Make Your Module Searchable So far, you know everything you need to know to get a basic module up and running. There are a few items we still need to cover regarding the configuration of your module so that it can […]
  • DotNetNuke – Modules – Linking within the moduleDotNetNuke – Modules – Linking within the module Now that we have the module skeleton up and running and we have a data access layer, the next thing we need to look at is specific functions you may need to use from within your code. One […]
  • DotNetNuke Modules – Where Stuff Shows UpDotNetNuke Modules – Where Stuff Shows Up We continue our series on creating DotNetNuke modules today by showing you where the various components of the module we created last week show up in DotNetNuke.Remember, last […]

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.

  • Nick

    Hi I have an error at this point originating in the in the Controller.cs

    “Error: The type or namespace name ‘Data’ does not exist in the namespace ‘BIP.DNN.Modules.Store’ (are you missing an assembly reference?)”

    Can you offer a suggestion?

  • Dave

    Yeah.. you are missing a using statement or you haven’t referenced a DLL that you need…just like it says.

    If I had to guess, I’d say you are missing

    using System.Data;

    at the top of your CSharp file.

  • Nick


    Thanks, but no that is what I checked first. System.Data is there.
    I think I may have misnamed the Provider namespace…

  • http://www.coultertechnologies.com Ethan

    Ok maybe I missed something but I got the BLL section and am I creating a new file for each class or just lumping them in the current controller class? Also, Does the namespace need to be prefix.DNN.Modules.Store.Business or can I continue with the prefix.Modules.category?

    What is the data namespace?

    Thanks for all your help.

  • Dave

    I’m not sure I entirely understand your question. But, let me try to answer it.

    I normally have a separate BLL (Controller) class for each table. This isn’t a hard and fast rule as long as you are consistent from the Interface, if you have one, on down to the implementation class.

    Namespaces are only there to keep things organized. You can call them whatever works for you but the “standard” way of dealing with it would be to have one for your Business classes (BLL) and one for you Data classes. But if you are using the DataSet method like I propose, you can just stick with what Visual Studio gives you for that namespace. I personally never had trouble finding it so I’m not sure what namespace it ends up under.

  • kolors


    What 2 namespaces this program needs? I don’t understand.

  • kolors

    1. namespace – MyCompany.Modules.MyModule
    2. namespace – DotNetNuke.Data

    Correct? Thx!

  • Dave


    You will not be able to compile at this point in the process. This is a step along the way.