Before there were Web parts, DotNetNuke created installable private assemblies nicknamed modules to encapsulate the functionality desired within a modular environment. It doesn't take much experience developing modules for DotNetNuke before you start asking the age-old questions: I know that it's powerful, but where do I start? I know this is handled in DNN, but how? How do I structure the module and create the installable package? At this point you are most likely starting to think instinctively about how to utilize a combination of existing tools and reusable code or templates to streamline development time.

In the DotNetNuke community, one of the most commonly asked questions is how to integrate CodeSmith or MyGeneration templates to create the Data Abstraction Layer (DAL). This article will hopefully open new paths of development by discussing a complete set of methods and tools to rapidly create modules for DotNetNuke. Although creating a series of templates that will cover the variety of elements required for even the simplest module seems like a daunting task in itself that requires learning a new variety of languages, there are a few packages that have been circulated that consist of all of the rudimentary elements to use CodeSmith to autogenerate the data access methods and database scripts. The actual coding and creation of the business objects, the user interfaces, and the construction of the project itself remains entirely manual when using CodeSmith to generate the CRUD.

The DAL Builder Pro tool by BonoSoft enhanced this functionality by generating a fairly complete module from the tables of a database, but still the actual coding and creation of the user interfaces and the construction of the project itself remains entirely manual. With the release of the ATGen SDK from AppTheory, all this has changed.

Understanding Custom Business Objects
When DotNetNuke adopted the provider pattern for its data layer, many developers who were familiar with creating methods using hard coded SQL queries, SQL helper functions, or DotNetNuke's own SqlCommandGenerator class were left with a new process that was shrouded in mystery. A very common question is how the DataProvider and SqlDataProvider combine to supply the data access functionality. The relationship exists as a type of contract that is held between the two parties and enforced by the methods, their parameters, and return types. When something is changed in the DataProvider, those changes must be reflected in the SqlDataProvider and vice versa. Because the SqlDataProvider, as a separate project, contains a reference to the module project that houses the DataProvider class, any changes to the DataProvider will show up as errors in the SqlDataProvider, because the signature of the methods, parameters, or return types does not constitute a match for the MustOverride methods provided by the DataProvider. Likewise, those same changes in the DataProvider will show as errors in any code that invokes those methods until the contract is restored. It is very helpful to complete these changes in a common fashion tailored to your development tastes, so that when changes occur it is fairly transparent to the developer which code was changed, and which is showing errors because it requires changes - or you could find yourself undoing necessary work to attempt to restore that contract. As always, it is best to have a prescribed development protocol to follow.

One of the nicest features of the ATGen SDK is how you can regenerate specific parts of your module code to update only what is necessary after changes to the database, which saves all that hassle but leaves your sensitive business logic intact. In other cases you need to regenerate vast portions of the module, possibly adding new controls to handle the data entry for a new table or columns, but you still need to leave the business logic intact. This too is handled by using an inherited stub class as the generated business layer, so all of your custom changes can exist side by side without fear of losing the code when regenerating.

The way that DotNetNuke uses a Custom Business Object (CBO) to supply a strongly typed class for each object is central to understanding the DataProvider pattern. This class exists solely to house the public properties and the private variables that represent the results of the DataReader. These types of classes are called info classes, and for best results in a wide variety of use cases they should be stored in a separate assembly or project than the rest of the module. By storing these property classes in their own assembly you guarantee the utilization of these classes without requiring a reference to the business or presentation classes. In the ATGen SDK module structure, the info classes are actually contained within the central project for simplicity, which is suitable for most modules.

The CBO serializes these info classes into their respective types, passing the classes through the DataProvider to the selected SqlDataProvider, or Access/Oracle/MySQL provider. Until recently there was no definitive tool to aid in the creation of these info classes, their accompanying logic classes, or their DataProvider methods, which remained a cumbersome and time-consuming burden for developers who were sure there was a better way to spend their time.

The DAL Builder from BonoSoft is a popular application that takes a defined data structure and produces the data layer for you, and has become a popular and timesaving utility with a low price tag. The ATGen SDK from AppTheory takes all of this to a new level by adding not only complete generation of the stored procedures, DAL, CBO, and info classes, but also creates the module project in its entirety. In fact, the module itself can be compiled with the open source tool NAnt using the accompanying build file included in any ATGen SDK-generated module package.

To those who are already familiar with code autogeneration tools, this may not seem to be a revolutionary accomplishment, but the best part about the ATGen SDK is that it is completely free, and it is tightly integrated with MyGeneration (which is also free). Overall, the ease of use and the lack of a learning curve to use the tool could allow someone without any technical or development skills to quickly generate a complete, ready-to-install module in under 10 minutes from any existing database tables!

Although this article is not intended to be a tutorial on how to use any of these tools, it is essential to understand the available products that can dramatically increase your productivity (for a complete tutorial on the AppTheory ATGen SDK, see the References section). The remainder of the article will show the steps required to plan, create, and implement a module for DotNetNuke, and demonstrate how incredibly easy these tools can make your development cycle.

Designing the Database Tables
Because the database is such a central point of code generation, the tables must be created with a few things in mind to produce the most effective, complete result when the module is generated:

• Each table that will be used in the generation process must have a single primary key field, which is set to Auto-Increment. The ATGen SDK has a few problems with tables with multiple primary keys in that it does not generate the corresponding components correctly, so a single primary key should be considered a requirement when designing these tables for code generation.
• Foreign Key Constraints should be enforced between the related tables that directly correspond to your module. These foreign keys are essential to the generation of a complete module that follows the rules set forth in your database. With foreign keys fields, there is autogeneration of the stored procedures that filter the results to the foreign keys, which saves considerably on coding later. For example, if you have a table named Pages with the three columns PageID (primary), PageName, and ChapterID (foreign key from the table Chapters), the ATGen SDK will automatically create the stored procedures and business methods to return the results by PageID or ChapterID.

Using the ATGen SDK to Create Your Module
First, we will open the ATGen SDK Master Template in MyGeneration by clicking on the desktop icon, or the start menu (see Figure 2).

Now we need to run the template within MyGeneration by clicking on the Play button. This loads the ATGen SDK program and begins the setup of your custom module.

The CRUD tab (Figure 3) contains the elements for configuring the Data Abstraction Layer for your module, including the CRUD Stored Procedures. After selecting a database to use, select the related tables pertaining to this module. It is essential to follow the steps defined in "Designing the Database Tables" for complete CRUD generation during this step. In most cases you can leave the defaults for the prefixes of the different CRUD actions, but it is very important to properly name your module project now by choosing a unique, case-sensitive name for the Project Name field, which corresponds to the naming convention of your other modules.

Now you are ready to save the settings you have defined, so you can regenerate the DAL for this module later if something changes in the database design down the road. I generally just name the template the same as my project name, like Initials_ProjectName_DAL. Once the template is saved, click on the Generate button to create the SQL scripts and add the stored procedures to your database.

There are some quirks in the database script creation that still need some fleshing out, but overall this works extremely well.

Now that the CRUD is created, you are ready to create the rest of the module. On the Module Code tab (Figure 4), you need to define a few properties to define this module. The Project Name should be the same as the one you defined when creating the CRUD template, and is case sensitive. Select the database to use for this module, generally the same one as you used in the CRUD generation, then click View Objects to confirm that the generated objects are what you desire. This will show a list of the Stored Procedures and Tables in your database that were created using the CRUD template.

Fill in the Company Name, which generally consists of the initials of your company. Then fill in the Schema Prefix, which is usually the same as the project name. In most cases, I suggest that you leave the Object Qualifier field empty.

Now for the final settings, and your module will be ready to generate. There are two types of project references that you can choose for your private assembly, which determines if the reference to the DotNetNuke assembly is a Class Project or a Web Project. I suggest using a Class Project as the reference type for your modules, because this choice allows for easier project management later, and decreases the build time.

The GUIDs that are generated for your module must be unique to this project, and are preset - you should not need to change these settings. Now select "Everything" in the Code Generation drop-down list to create the complete module project. As in the CRUD step, you should save these settings prior to code generation so that you can regenerate the module code later if anything changes in the database. Now just kick back and click the Generate button to watch the magic happen.