Thoughts from the Wet Coast
The musings of an ASP.NET Developer from Canada's We(s)t Coast
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.
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.