What is SnapDAL?

SnapDAL for .Net is a combination of a data access helper and a Factory that supports the use of the generic ADO.net interfaces. It is also integrated with the unit testing framework, .NET MockObjects, which supply mock implementations for ADO.net. SnapDAL was built with the idea of helping you write testable data access code by support Mock Objects natively as a first class part of the tool. The roles of data access helper and of factory are shown in the simple examples below.

Show me the code!

The most important thing to understand about how SnapDAL works is that you will write code similar in style to standard ADO.Net code except that you will usually be writing against the generic interfaces in System.Data. For example to execute the dynamic SQL below:

using SnapDAL;
using System;
using System.Data;

...

DataFactory factory = new DataFactory("your connection string", "SqlClient");
string sql = "select * from customers where companyname = '" + cname + "'";

IDbCommand comm = dal.CreateCommand(sql);
comm.Connection.Open();
IDataReader rdr = comm.ExecuteReader();
if (rdr.Read())
   //do something
rdr.Close();
comm.Connection.Close();

Second, SnapDAL provides an abstraction on the actual commands used against the data source so that you can effectively have an application specific Provider Model of your data. This is done by organizing your actual SQL, or other provider messages, into Statements that have a name that makes sense to your application. These are stored in any folder you can specify, or in the bin folder of your app. So, with your sql defined in bin/Customer_Load.config, the example would like like this:

DataFactory factory = new DataFactory("your connection string", "SqlClient");
IDbDataReader rdr = factory.ExecuteDataReader("Customer_Load");
while (rdr.Read())
  //do something
rdr.Close();

 

Note some important things about this code.

• There is no sql statement here. With SnapDAL, SQL is (usually) stored in files in the Statement directory, the bin folder of you app by default.
• There is no call to setup or open the connection. You can have complete control over that, but it taken care of for you by the DataFactory.
• Coding is done against the generic ADO.net interfaces
• The specific ADO.net provider is specified in setup of the DataFactory.

If you are ready to dive in, look at the samples and at the API documentation. Otherwise, continue on to the introduction