Simplifying Data Access for the Repository Factory - Still Using SqlHelper??
by David Hayden ( Florida .NET C# SQL Server Developer ), Filed: Enterprise Library
A couple of weeks ago I talked about creating a pluggable provider for the Repository Factory so that it wasn't dependent on Enterprise Library:
Repository Factory With Pluggable Database Provider - 4 Hours Including Custom Tooling
My post wasn't a bash against Enterprise Library but reflected a real world scenario where I have clients that wanted to use the Repository Factory but did not want to use Enterprise Library. Unfortunately, the Repository Factory ( and most software factories ) have a needless dependency on Enterprise Library which makes it difficult to use with clients who already have their own infrastructure layer services. I fixed that for a client by applying simple design patterns that made Enterprise Library a provider as opposed to a dependency.
Since then, I have received a couple of comments from readers who would like to use the Repository Factory but are concerned about the overhead of the DAAB as compared to the old SqlHelper, which some people still use today surprisingly. Honestly, I think the overhead is minimal, and that it only feels like more overhead because you have 3 assemblies:
-
Microsoft.Practices.ObjectBuilder
-
Microsoft.Practices.EnterpriseLibrary.Common
-
Microsoft.Practices.EnterpriseLibrary.Data
instead of one as with SqlHelper. This is just a natural separation of responsibilities that we have multiple applications blocks as well as increased functionality.
However, a concern is a concern, so my goal last night was to just simplify the DAAB so it no longer required ObjectBuilder, the Common Assembly, and anything else associated with Enterprise Library. Let's break it down into its bare essentials so that it will still work with the code generated by the Repository Factory. Here are the results:
I had to pull over 8 classes from the DAAB and applied a little convention over configuration to eliminate ObjectBuilder and the Common Assembly. I did lose some functionality in my bare essentials version. At a minimum I lost:
I simplified the DatabaseFactory Class just to focus on my need for SQL Server:
public static class DatabaseFactory
{
public static Database CreateDatabase()
{
return CreateDatabase("ConnectionString");
}
public static Database CreateDatabase(string name)
{
string connectionString =
ConfigurationManager.
ConnectionStrings[name].ConnectionString;
return new SqlDatabase(connectionString);
}
}
This is a bit of a gross oversimplification that assumes a default connection string name of "ConnectionString" and doesn't check to see that the providerName on the Connection String is "System.Data.SqlClient". You can obviously grab the default connection string in an AppSetting as well as check for the providerName, etc., but I am just getting things to work :)
If you wanted to add support for Oracle and other databases by pulling over the OracleDatabase and GenericDatabase Classes, you could do that with a little bit more work. I am not sure how much work since there is some extra configuration for Oracle Packages, but it wouldn't be that much effort.
My point isn't to recommend doing this, but to show that you have options. You have all the source code for both the Repository Factory and Enterprise Library that you can bend to your will.
Apparently, you can still download the SqlHelper if you really don't want to use Enterprise Library, but I might be more inclined to rip apart the new version of the DAAB as mentioned above so I can take advantage of the code generated by the software factories as well as move to Enterprise Library in the future if that is an option. Just a thought :)
Source: David Hayden ( Florida .NET C# SQL Server Developer )
Filed: Enterprise Library