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
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.
NULL
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.
Well - its official - I am doing a fall speaking tour this October. A few months ago, when the schedule was announced, I found out that I would be speaking at DNN World in Orlando (Oct 10-12, 2012).
I will be presenting a session on Knockout.js.
About the same time as I submitted sessions to DNN World I also submitted sessions to a couple of other conferences that are being held in the fall, and just over a week ago I heard that I was invited to speak at DevReach in Sofia, Bulgaria - the home of Telerik. DevReach is exactly a week before DNN World (Oct 4-5, 2012).
I will be presenting two sessions at DevReach and readers of this blog will not be surprised with the topics chosen.
In combination with these conferences I will be spending a few days in England visiting my Mum and sister, and I am speaking with a few UK User Groups to see if I can line up one or two User Group meetings while I am there.
In part 3 of this series on DotNetNuke Module Development we created our first module “Hello World”. In this blog I will describe a second way that you can create modules.
The next method we will use is to create the same User Control (ascx file) in a simple IDE like WebMatrix. WebMatrix is a free download from Microsoft, so is an excellent choice for novice or hobby developers who are just starting out on DotNetNuke development.
Back in April I started a series of blog posts on DotNetNuke Module Development. So far we haven’t actually done any development, so in this blog post we will create our first module, and in the long-held tradition of software development - lets call it Hello World.
In part 2 of this series I mentioned that the only thing required by a module was that it needed to implement the IModuleControl interface...
The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.