DotNetNuke Modules – Data Access Layer
August 5th, 2008 | 
Author: 
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
- Creating DotNetNuke Modules - May 20th, 2008
- Creating DNN Modules - The Tools - May 22nd, 2008
- DotNetNuke Modules - Foundational Concepts - May 26th, 2008
- DotNetNuke Modules - Install DNN into VS 2008 - May 27th, 2008
- DotNetNuke Modules - Creating Base Modules - May 28th, 2008
- DotNetNuke Modules - Registering Your Module - May 29th, 2008
- DotNetNuke Modules - Where Stuff Shows Up - June 3rd, 2008
- DotNetNuke Modules - Benefits of Architecture - June 4th, 2008
- DotNetNuke Modules - Anatomy of the View - June 9th, 2008
- DotNetNuke Modules - Adding Actions - June 11th, 2008
- DotNetNuke Modules - DNN Controls - Label - June 18th, 2008
- DotNetNuke - Internationalization - June 25th, 2008
- DotNetNuke Modules - Internationalization (part 2) - June 30th, 2008
- DotNetNuke Modules - Labels w/ no Help - July 9th, 2008
- DotNetNuke Modules - LinkButtons - July 14th, 2008
- DotNetNuke Modules - Collapsible Panels - July 16th, 2008
- DotNetNuke - The Data Layer - Installing CodeSmith - July 22nd, 2008
- DotNetNuke - Modules - Creating The Tables - July 24th, 2008
- DotNetNuke - Modules - Creating Stored Procs - July 29th, 2008
- DotNetNuke - Modules - Portal Specific Modules - July 31st, 2008
- DotNetNuke Modules - Data Access Layer - August 5th, 2008
- DotNetNuke Modules - Data Access Layer - August 7th, 2008
- DotNetNuke - Data Access Layer Alternative - August 12th, 2008
- DotNetNuke - Modules - Linking within the module - August 14th, 2008
- DotNetNuke - Make Your Module Searchable - August 19th, 2008
- DotNetNuke Modules - Making Content Portable - August 25th, 2008
- DotNetNuke Modules - Exceptions the DNN Way - September 2nd, 2008
- DotNetNuke Modules - PortalModuleBase - September 4th, 2008
- DotNetNuke Modules - Inter Module Communication - September 9th, 2008
- DotNetNuke Modules - Finding The Page a Module is On - September 15th, 2008
- DotNetNuke Modules - Caching - September 17th, 2008
- DotNetNuke Modules - Module Settings - September 22nd, 2008
- DotNetNuke Modules - Retrieving Settings - September 24th, 2008
- DotNetNuke Modules - Advanced Architecture - October 20th, 2008
- DotNetNuke Modules - Creating the PA - October 30th, 2008
- DotNetNuke Modules - Automating the PA - November 5th, 2008
- DotNetNuke - FileUploadControl Danger! - February 26th, 2009
- DotNetNuke SecurityException AspnetHostingPermission - October 14th, 2009
- Changing an Existing DNN Module - March 4th, 2010
Other Related Items:
SUPERMICRO X6DAL-XG - mainboard - ATX - E7525 ( X6DAL-XG BULK )The X6DAL-XG supports single or dual Intel Xeon Nocona processors at a 800 MHz front side bus. Based upon Intel's NetBurst microarchitecture with EM64... Read More >
Da Vinci Ruote, Italian 100% Plastic Playing Cards, 2-Deck Poker Size Set, Regular Index, w/2 Cut CardsNote: As of Feb/20/2010 all sets come with new hardshell plastic case and 2 Free Da Vinci cut cards as shown. Da Vinci 100% Plastic playing cards are ... Read More >
Sleeping Beauty (Two-Disc Platinum Edition)Disney's 1959 animated effort was the studio's most ambitious to date, a widescreen spectacle boasting a gorgeous waltz-filled score adapting Tchaikov... Read More >
Related Post
Posted in 
Tags: 8 Responses to “DotNetNuke Modules – Data Access Layer”
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?
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.
Hi,
Thanks, but no that is what I checked first. System.Data is there.
I think I may have misnamed the Provider namespace…
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.
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.
HELP!!!!
What 2 namespaces this program needs? I don’t understand.
1. namespace – MyCompany.Modules.MyModule
2. namespace – DotNetNuke.Data
Correct? Thx!
Guys.
You will not be able to compile at this point in the process. This is a step along the way.