Design Diary: An Interface-Based Approach toward the System.Data Namespace
The first episode of the four-part design patterns series, “Jean-Paul Boodhoo on Demystifying Design Patterns Part 1,” brought to my attention an interface-based approach toward the System.Data namespace. My earlier priority was expressing support for the System.Data.Common namespace—and this priority comes with the demand that you have to support the System.Data.Common namespace or you can’t work with my data access solution.
By overloading my System.Data.Common static helpers with relevant System.Data interfaces, the scope of my data access solution broadens. Now my new demand is, ‘Your data provider must implement the relevant System.Data interfaces (e.g. IDbConnection, IDbCommand, IDataReader, etc.) in order to work with my code.’ This effectively means that your database must support the .NET framework itself in order to work with the Songhay System Data Access Framework. This is a remarkable achievement and it only took me over a year to reach this very simple place. Sorry, Jean-Paul!
This little re-factoring adventure yields a few, minor Funky Knowledgebase articles:
- “C# 2.0 Code: Converting from IDataParameter to DbParameter[] with Array.ConvertAll<>() and an Anonymous Delegate”
- “C# 2.0 Code: Using a Generic List<T> to Build an Array from a Generic Dictionary<String, Object>”One fascinating moment in “Jean-Paul Boodhoo on Demystifying Design Patterns Part 1” revealed the System.Data.Common.DbProviderFactories under layers and layers of Test-Driven design talk. So it still seems correct to prioritize the
System.Data.Commonnamespace. But this is not an either-or confrontation, this is a both-and conversation. In fact,System.Data.Commonobjects implement all of the correctSystem.Datainterfaces.