Make the most of the Data Access Application Blocks

Shameless plug here today: I've talked about the Data Access Application Blocks here before, but today Connect for ADO.NET released support for the for the DAAB code blocks supplied in the Enterprise Libraries. You can now configure the DAAB with Connect for ADO.NET by following some quick and easy steps - scroll down for details...

The DAAB code blocks do an excellent job at abstracting away ADO.NET coding specifics, if you the architect is looking to shield your developers away from data source variances, particularly in a heterogeneous database environment Add the Connect for ADO.NET providers into the mix you can architect true code data blocks that offer SQL Leveling, best-in class performance and host of other features that bullet proof your blocks for many years to come.

Curious as to how to do this ? Use these instructions sourced from here, this is a quick guide to get your started. Great job from Betsy to get this together in such short space of time:

Configuring the Data Access Application Block consists of two parts:

• Adding a New DAAB Entry
• Adding the Data Access Application Block to Your Application

Adding a New DAAB Entry

Now, use the Enterprise Library Configuration Tool to add a new DAAB entry:

1. Right-click Enterprise Library Configuration, and select New Application.
2. Right-click Application Configuration, then select New / Data Access Application Block. The Enterprise Library Configuration window appears.
   
   
3. In the Name field, enter a name for the DAAB, for example, MyOracle.
4. In the ConnectionString field, enter a connection string.
5. In the ProviderName field, identify the DataDirect data provider:
   1. For DB2, enter DDTek.DB2
   2. For Oracle, enter DDTek.Oracle
   3. For SQL Server, enter DDTek.SQLServer
   4. For Sybase, enter DDTek.Sybase
6. Right-click Customer Provider Mappings and select New / Provider Mappings.
   
   
7. In the Name field, type the DAAB name entered in Step 3 (MyOracle).
8. In the TypeName field, choose the browse (...) button and navigate to the Debug output directory of the DataDirect DAAB that you want to build.
9. Select the file name, for example, DDTek.EnterpriseLibrary.Data.Oracle.dll, and then click Open.
10. Leave the Enterprise Library Configuration window open for now. Do not save this configuration until you complete the following section.

Adding the Data Access Application Block to Your Application

To add the DAAB to a new or existing application, perform these steps:

1. Right-click the project and select Add Reference.
2. In the Add Reference dialog, select Enterprise Library Shared Library, and click OK.
3. Right-click the project and select Add Reference.
4. In the Add Reference dialog, select Enterprise Library Data Access Application Block, and click OK.
5. Add the following directive to your C# source code:

   using Microsoft.Practices.EnterpriseLibrary.Data;
   using System.Data;

6. Rebuild the solution to ensure that the new dependencies are functional.
7. Determine the output Debug or Release path location of your current solution, and switch back to the Enterprise Library Configuration window (see "Adding a New DAAB Entry" on page 3).
8. Right-click the connection string under the Application Configuration node and select Save Application.
   
   
9. Navigate to the Debug or Release output directory of your current solution, and locate the .exe file of the current solution, for example, MyApp.exe.
10. Click the file name once, and add .config to the name, for example, MyApp.exe.config.
11. Ensure Save as type 'All Files' is selected and select Save.
12. Using File Explorer, copy the DDTek.EnterpriseLibrary.Data.XXX.dll from the DataDirect DAAB directories (where XXX indicates the data source).
13. Place a copy of this DLL into either the Debug or Release output directory of your current solution.

The .NET Framework catches a case of openness

The .NET Framework has developed with uncharacteristic malaise; likely diagnosis: it has come down with a surprising and puzzling case of openness.

Scot Guthrie, provides some of the fine print:

“We’ll begin by offering the source code (with source file comments included) for the .NET Base Class Libraries (System, System.IO, System.Collections, System.Configuration, System.Threading, System.Net, System.Security, System.Runtime, System.Text, etc), ASP.NET (System.Web), Windows Forms (System.Windows.Forms), ADO.NET (System.Data), XML (System.Xml), and WPF (System.Windows). We’ll then be adding more libraries in the months ahead (including WCF, Workflow, and LINQ). The source code will be released under the Microsoft Reference License (MS-RL).”

As yet, not one opinion appears to be dominating as to what this might mean. Some of my favorite examples include Fake Steve is already scoffing at the move, while assuring us all that Apple will never stoop to this. Robert Scoble is characteristically derisive in his analysis. Others believe this move is a tacit acknowledgment of Microsoft’s failure to capture the imagination of a broader developer community. Others don’t see it affecting them much, while at the extreme, the howls of delight from competing development platforms and paradigms is almost deafening…

What this means for the likes of Novell’s effort towards delivering Mono, nor has anyone commented on how this might affect newly invigorated Novell/Microsoft marriage of convenience.

Before I offer an interpretation of what this means first let me re-iterate my context:

This blog serves a number of perspectives, base on my experiences from the open source, Java community and now the .NET work development platforms – great care is taken to avoid spouting or worse still regurgitating cool aid and of bile from other sources.

Exposing the internals of the .NET Framework is I believe the tip of the ice berg. Think back to early attempts by the Java platform to adopt a more open stance and move away from the ivory tower and provide more inclusive processes for the Java community at large. I think it is safe to say that we can and should expect to see additional baby steps from Microsoft on this score. Moves such as this often have halo-affect, which spurs innovation, discussion and ingenuity that is difficult to predict but is over-all beneficial to the adoption of any platform.

An important distinction here is that Microsoft is make strides toward an more open and inclusive process. I think it’s unlikely we will ever see the equivalent of the JCP for .NET, but my hope it we will see the emergence of a community framework that will facilitate contributions and motivate people to bleed back their ideas into the platform. It is actually an implicit good develop for Java too: a move such as this may be dismissed, but I am sure there are those in the Java community who will give in to their curiosity and peal back the covers on the .NET internals …