DAL 2 - Using the new Repository to Persist Objects - CBO on steroids

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.

Listing 1: The Task Model

As mentioned in the previous post the only sql that we need to include in our tasks module is the sql to create the Tasks Table.  Entity Framework Code First, and other OR/Ms can auto-generate the schema based on the objects, and this is a feature that is being considered for a future enhancement of the DAL2.  The sql to create the Tasks table in a database that is using the “dnn_” object qualifier or table prefix is shown in Listing 2.

Listing 2: The Create Table SQL to create the Tasks Table

Before we go any further and start to create our Business Layer methods, lets take a closer look at the Task class and associated Tasks table.  The first thing that jumps out is “How does the DAL 2 know to map the TaskId property to the ID column in the database. 

In fact it doesn’t know what to do and we have to tell it how to do the mapping.  The DAL 2 is built on PetaPoco and PetaPoco provides some convention based rules as well as an IMapper interface to handle mappings that don’t follow the rules.  There are two basic convention based rules:

1. PetaPoco assumes that the table name will be the plural of the object being mapped.  
2. PetaPoco assumes that the column names are the same as the property of the object. 

I will discuss custom mappings and the IMapper interface in a future blog, so for now we will change the name of the primary key to TaskID so the Class and Table follow the PetaPoco conventions - see Listing 3.

Listing 3 : Modified Create Table SQL

So now we are ready to create our Business Layer methods, assured that the DAL2 will know how to map our Task objects to Tasks records.

Listing 4 shows the CRUD methods to Create, Retrieve, Update and Delete a Task.

Listing 4: The TaskController Business Layer methods

All of the methods are similar - we call the DataContext.Instance method to get the default instance of the IDataContext interface.  We don’t intend to provide any other implementations of IDataContext, but this pattern supports the ability to mock the IDataContext interface in Unit Tests.  The PetaPocoDataContext instance returned implements IDisposable so we can use the C# using statement.  Inside the using code block we get an instance of IRepository of T where T is our Task in this case.

Its pretty amazing, but that is all the code you need to write to create the business and data layers for a simple module.

But there is more; custom mappings, data scoping, caching and transaction support is also included and in future blogs I will describe how they can be used in your modules.

Have fun experimenting with the CTP and please give us feedback on this new exciting feature.