Thoughts from the Wet Coast
The musings of an ASP.NET Developer from Canada's We(s)t Coast

In this series I intend to present Tips and Tricks as well as some good patterns and practices for DNN development.  In this first post lets take a look at the so-called “SOLID” Design Principles.  These are a series of principles designed to help you build good products.

A couple of years ago I started a series on DotNetNuke Module Development but I didn’t get very far. Recently, I have been working on a new DNN Module Development video training course for Pluralsight and I have decided to use that module development course as a template to restart this series on how I think about DNN Module Development.   Hopefully this time I will be able to provide you with some best practices on DNN Module Development.

I continue my deep dive into DotNetNuke 7’s new DAL 2 with a look at the features that make up the repository component.

The IRepository of T interface can be considered the core of the new DAL 2. While the Execute methods of the IDataContext interface provide a DAL + like API, the benefits of the new API are really found when using the repository. The Repository Pattern is a common design pattern in modern data access layers.

So far I have done a relatively high level review of the DAL 2 API. In this blog article I will start to take a deep-dive into the components that make up the API, beginning with the DataContext.

The IDataContext interface and the PetaPocoDataContext concrete implementation act as the entry point into most aspects of the DAL 2 API. While implemented as an Interface there is no expectation that any other implementation will be created, but the interface allows us to mock a concrete implementation for Unit Testing purposes.

I presented a session on the DAL 2 at DNN World in Orlando, and a few people asked about “calculated” properties - or properties that do not have any matching column in the database.  This is an important feature for any “auto-mapped” repository implementation, so we have added three new Attributes that control the mapping of properties and columns.

So far in my review of the new DAL2 I have focused on the features designed to improve developer productivity - i.e. the Repository.  In this post I am going to step back and look at other features which mimic the existing DAL+, and provide the developer with a sense of working “close to the metal”.

This is the third blog in my series describing the new DAL 2 data layer that we are introducing in DNN 7.  In the first I gave an introduction into why we were introducing a new data Layer, and some of the basic features it provides, and in the second article I introduced the new built in IRepository of T implementation.

In my previous blog on the new DotNetNuke Data Access Layer, I introduced why we were building a new Data Access Layer and the basics about what the layer includes.  In this blog I will dive a little deeper into how module developers can take advantage of the new DAL 2 by using the built in IRepository of T implementation to simplify their module development.

So that you don’t have to refer back to the previous post, Listing 1 shows the same TaskInfo (model) class that I showed in the previous post, except I have renamed it to Task, and I have removed the ModuleId property, which means that any instance of the module will return the same set of Tasks.  In a future blog I will discuss features of the DAL 2 API that allow you to scope your data.

DotNetNuke has essentially used the same data access layer since its earliest versions.  This data layer uses an abstract DataProvider class together with a concrete SqlDataProvider class. 

In theory this model supports the ability to use other database systems by building other concrete DataProvider implementations.  However, in practice this is actually not very practical for a number of reasons, the main reason being the need to create database scripts for each concrete provider.  As a result, there really aren’t any other database implementations available.

In our series on developing DotNetNuke Modules I have covered two ways to create a simple module - using DotNetNuke itself, and using WebMatrix.  In this post I will show how Visual Studio can be used to create a similar Hello World module. 

Before we do that lets take a more detailed look at the module control itself.  As the examples in Hello World and Hello World 2 are similar, we will focus on the first example.