SnapDAL FAQ

Fact is, there haven't been too many questions yet, but here are some of the more obvious ones from our own time working with SnapDAL

• Q - Is SnapDAL ready for production?
• A - The DataFactory class in the VB version has been used for millions of database calls and transactions. The c# version has been in full production since April of 2004 and has also handled millions of transactions since that time. The DataFactory code and interface has not changed hardly at all since the orginal version. However the underlying Mock functionality is still early beta quality and the api may be subject to change.
• Q - Why can't I just create some SQL in code and execute it?
• A - In the VB version, which was written by Dan Fox for Tech Ed 2002, he believed that parameterized queries were much more efficient that building dynamic SQL in code and executing that. This is a common belief that has only recently come under questioning. We believe parameterized queries are the most elegant way to do queries, however there are many many reasons not to do them, or why they may not be the best solution for you. The c# version of SnapDAL fully supports unparameterized queries saved as text files, inserted into the cache manually, or executed directly from sql created in text.

Here are some examples off things you can't do with parameterized queries:

• terms in an IN clause cannot be parameters. Ex. select * from customers where customerid in ('A', 'C', 'U')
• table names cannot be parameterized so that if you have separated data into related tables with similar schema you cannot do "select name from @tablename).
• O/R tools with their own query language may implement this as a sql query, but it would not be possible to know ahead of time what the text of the query would be.
• Many types of data providers don't take parameters at all. Ex: SnapDAL could easliy be used to produce readers and scalar results from and LDAP server.
• Q - Tool X has lots of code generation features, what about SnapDAL?
• A - SnapDAL has code generation functionality for the SqlClient that can do the following:
  • Generate Statement files from stored procs in your database
  • Generate a set of statements for a table in your database
  • With a CodeSmith template, generate Command objects with strongly typed parameters for your statements into a code region in your code (please ask via the mailing lists about this)
  • Generate recorded test files that can act as your test database during unit testing
• Q - Why should I use SnapDAL when Microsoft has the Microsoft Data Access Application Block (DAAB)?
• A - The advantage of a Factory based architecture has already been accepted by Microsoft as a superior way to go. Whidbey will provide this out of the block.
• Q- Why SnapDAL when Whidbey will provide a Factory for you out of the block?
• A - It is not clear what will be provided, as the beta has yet to be released. The intial overview however looked much more like the Provider class, a factory of IDbCommand, IDataReader, IDataParameter instances and so on. Every call still needed to organize connections, handle opens and closes, other busy work that SnapDAL does for you. And as far as we can tell, there isn't any data helper that works with mock objects, and that's gotta be cool ;-) The BSD license should make the choice as easy as choosing a framework api.
• Q - Is SnapDAL an O/R mapping tool?
• A - Nope. An O/R tool could be built with SnapDAL and we think it would be a good idea. Some research is being done in this direction already.
• Q - Can't I use mock objects without SnapDAL?
• A - Of course. However, you have to have a way to get your code to use those mock objects. The most widely used mechanism for substituting one type of instance for another, like a MockCommand for a SqlCommand, is to do this with a Factory method. SnapDAL provides both a Factory via Provider under the covers, and a simplified interface via DataFactory. To provide all of those features yourself, and to really support mock objects, is a lot of work. We know, we have been working on the task.
• Q - Do you have any suggestions for converting my old code to use SnapDAL?
• A - Unfortunately, a design time tool to parse your (or my) ugly ado.net code would be a LOT of work. We haven't done it. However, unlike most other tools like this, SnapDAL can actually work side by side with existing code, sharing connections and transactions. So instead of having to do a complete rewrite, you can work it in slowly.
• Q - Is there any commercial support for SnapDAL?
• A - Like all open source code, the support is in the form of mailing lists and free availability of source code to make it much easier to debug problems. There are no commercial companies providing support for SnapDAL. Quilogy, where the original author came from, is a training company so you could contact them and see if something is possible.
• Q - What are the correct parameter types to put in the config files?
• A - Good question. For the built in providers, the specific parameter types can be used. However, this is in conflict with the goal of virtualizing the database between providers, so the first choice should be to use normal clr types. There is a mapping between the clr types and provider specific types. If the provider specific type can't be matched, an attempt is made to map to DbType. Finally, an exception is thrown. Also, when using the clr types, or the specific types, the best results will be had when using lower case characters
• Q - Is everything case sensitive?
• A - Assume it is and you can't go wrong. In truth, some parts are and some parts aren't and it's beyond the control of SnapDAL. The filesystem name would match correctly on "Query_customer" or "query_customer" because File.Exists is case insensitive. However the statement name in the file gets used in a hashtable, which is always case sensitive. Similar issue with parameter names. The SnapDAL version of the name is case sensitive, but database parameters are not case sensitive unless the database insists it is. Just assume case sensitive names for everthing and you can't go wrong.
• Q - My alternate reader has no errors but no data either?
• A - Pay attention to some key factors. If you just got the mock command you intended to use with factory.GetCommand("statementName") you probably aren't getting the parameters passed correctly. Parameter values only get added to a command during the clone of the command, something the data factory does automatically for you.
• Q - There is so much going on behind the scenes, how can I figure out what's wrong?
• A - First, you can turn on tracing. There is a setting you can add to your application config file, or in a config file NUnit uses based on the dll name of the assembly containing the tests. The section looks like this:

    <system.diagnostics>
       <switches>
           <add name="dfSwitch" value="1" />
       </switches>
       <trace autoflush="true" indentsize="4">
           <listeners>
               <add name="myListener" type="System.Diagnostics.TextWriterTraceListener" 
                   initializeData="myListener.log" />
           </listeners>
       </trace>
     </system.diagnostics>
    
    

  This will turn on tracing which is then put in a the log file myListener.log. If you are running in visual studio, vs will display all trace output in the Output window of the ide with the Debug section selected. Tracing is not turned by default however because of the performance hit. Tracing is always used in the Mock.Util class because there is no downside to having it on during development.