Posted by: Michael Washington
2/22/2006 

The current plans for the DAL II are much different than the original proposal at: http://adefwebserver.com/DAL/ . However the result is the same: “Simplify module development by a reduction in code and complexity.”

In the original DAL II proposal, we used the Microsoft Enterprise Blocks. Using the Enterprise Blocks we created a MS SQL Server data provider and an Access data provider for the Survey module. What we did was configure the Enterprise Blocks to execute stored procedures when passed parameters. For Microsoft Access I created a way to simulate stored procedures in Microsoft Access using a dynamically loaded assembly. All a module developer had to do was change the current provider and create stored procedures or a custom assembly for the new data source.

Then I started working on the Firebird project and discovered that 90% of the MS SQL Server stored procedures could be recreated but about 10% could not. For those that could not be converted we would need multiple stored procedures to simulate the functionality of one MS SQL stored procedure. The current DAL handles this with no problem (the Firebird provider project is using the current DAL). If we used the DAL II we would be forced to use the dynamically loaded assembly method and that would be MORE coding than the current DAL not to mention slower performance.

The Core has decided that it did like some aspects of the DAL II proposal, namely that it allowed the module developer to:

• Make calls to the database directly from the “controller” class
• Not have to code a separate data provider

These are the things that made the DAL II so appealing. The Core then came up with a way to implement the 2 points above while avoiding the problems we encountered with the Firebird provider:

• Keep the current DAL
• Add “Generic Methods” to ease module development.

The new "Generic" methods are:

• ExecuteNonQuery

• ExecuteReader

• ExecuteScalar

This will allow a module developer to use code such as:

Public Function GetItems(ByVal ModuleId As Integer) As ArrayList
Return CBO.FillCollection(DataProvider.Instance().ExecuteReader("GetItems",ModuleId), GetType(ItemInfo))
End Function

in the "controller" class. The "Generic" methods will exist in all the concrete data providers (MS SQL, Oracle, Firebird, ect.). A module written for MS SQL using the DAL II "should" work in other databases and will in most cases. In some special cases where another database stored procedure cannot recreate a MS SQL stored procedure, the original module code would have to be adjusted to issue more than one call.

The Core DotNetNuke code will continue to use the existing DAL. Independent module developers will now have a choice.

I am currently at work on tutorials that will show how to use the new code when it is released.

Trackback Print

Tags:

Categories:

Location: Blogs Michael Washington