Question

I want to create a Data Access Layer that I can reuse with any type of SQL provider. What I don’t want is to have a switch statement that specifies different ways to obtain the id of the last created record for each known provider. Does DbConnection provide a way to access the the id of the last created record in a generic way?

Answer 1

I wouldn’t be optimistic about this. Some databases provide automation for creating ID values (SQL Server, MySQL, for example). The connection doesn’t automatically provide the value back to you, though; you have to ask for it. In SQL Server,

INSERT INTO FOO (...) VALUES(...); SELECT SCOPE_IDENTITY;

Oracle doesn’t even have the concept of an identity column. Generating an identity value means either taking the MAX + 1 of existing identity values, or using a SEQUENCE and a TRIGGER to add the identity value. Either way, you’d have to wrap it all in a transaction to guarantee correctness, and for the SEQUENCE solution, you’d have to run a separate SELECT to get the sequence value back (as part of the transaction). You’d probably have to do that with the MAX + 1 approach, too, but I haven’t gone that direction in any application so I can’t say definitively. Databases that have automated identity solutions don’t require a transaction to wrap each insert-with-identity-request.

In general, databases tend to support dialects of SQL, not a single “standard”, and they vary even more in terms of access methodology. Trying to support a “common subset” can mean that you narrow your possibilities too far to be useful. Taking an approach of DbConnection, DbCommand, etc., you’d be limited to generating GUIDs in application code, as the only alternative to get out of the identity column mess.

The other solution is an ORM, which maps a model onto an underlying (and well-hidden) access layer. Entity Framework tries to get there, but generating connection strings is problematic due to EF’s interdependence between model and connection string. The IQToolkit project on Codeplex takes a different approach of mapping LINQ onto databases, but it still needs plug-in providers that provide not only the unique connection implementation, but also SQL formatters and language policy modules that shape the generated SQL to the constraints of specific database implementations.

My feeling on this is that DbConnection is the wrong place to go looking for a place to start your commonality. Be sure you understand the quirks of each database that you need to support — meaning that you have to be very comfortable programming them before you start wrapping them in common access layers. Look at ORMs enough to understand how they work; the real commonality they can provide starts with “get me a referrer record with this identity” rather than “give me a connection”. They hide not only connections and commands, but also provide command generators, sometimes in tight collaboration with the database provider. Most provide results as classes mapped to either tables, models, or specific queries (based on LINQ, for example).

If you really want to hide the details of databases from the rest of your application, you have to hide everything. The abstract data access classes in ADO.NET won’t be sufficient.

Or you can fall back on ODBC, but that’s a different set of problems all on its own, in addition to being pretty much obsolete.