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.