Question

Note: My code happens to be in C#, but I don’t think that’s significant to solving the problem.

Problem

I’m trying to reduce code duplication in two old classes we have that are both used for loading queries from XML. They both have constructors that take the XML location, both have Execute methods that accept a collection of SQL parameters and both provide various static overloaded methods to make it quick and easy to run a query with maybe a single named paramater, or no parameter, or one with a non-default SQL connection object. These static methods also accept the XML location as the parameter, and internally they’re calling the constructor, and so on, and finally just returning the first DataTable of the DataSet.

public static DataTable GetQuery(string queryName) { ... }
public static DataTable GetQuery(string queryName, string parameterName, string parameterValue) { ... }
public static DataTable GetQuery(string queryName, Hashtable parameters) { ... }
public static DataTable GetQuery(string queryName, Hashtable parameters, IConnection connection) { ... }

and so on.

The difference between the two is that one looks for the XML file in the filesystem, and the other looks for them embedded in the assembly.

Possible Solution 1

I was thinking of unifying them into one that can do either, using different implementations of a separate IQuerySource interface, passed into the constructor, or something. But this would mean either the constructor would have to always be called ahead of time, or the GetQuery methods would need to be passed the IQuerySource object every time, as well. I’m trying to avoid things like that, because these GetQuery methods are used everywhere in the client code, for quick little things like GetQuery("GetUserDetails","UserID",userId.ToString()).

Possible Solution 2

Alternatively, I could create two very light classes, FileQuery and DllQuery, that would sit on top of the unified class, and they would always pass FileQuerySource and DllQuerySource down to the constructor and/or GetQuery methods. This would keep the client code small, but I don’t want to have maintain (marginally thinner) versions of all the existing GetQuery overloads in two more places, in addition to the core class!

Possible Solution 3

Another alternative would be like the above, but exposing the unified class so you could call, say, DllQuery.Q.GetQuery("GetUserDetails","UserID",userId.ToString()), but then I’m not sure how DllQuery can intercept the call and make sure the Q instance of the unified class always gets the right source for the job.

An additional complexity is that to get XML from an assembly, we’re currently using System.Reflection.Assembly.GetCallingAssembly(), so wherever that’s called has to sit directly under the surface of the client code, otherwise we’ll get our Data assembly instead of the client assembly.

I understand this question might be a bit subjective, but I’m hoping there’s some well-understood and well-defined design pattern, or something, for addressing this.

Answer 1

I think this is quite influenced by opinion, but I’d do this:

public interface IQuerySource
{
  // function GetXML(Assembly caller)
};

public class XmlQuery
{
  XmlQuery(IQuerySource source);
  // GetQuery functions
}

public class FileQuery : IQuerySource
{
  private FileQuery() {} // Only accessable through the Q property
  public static readonly XmlQuery Q = new XmlQuery(new FileQuery());

  // function GetXML(Assembly caller) for a file source
}

public class DllQuery : IQuerySource
{
  private DllQuery() {} // Only accessable through the Q property
  public static readonly XmlQuery Q = new XmlQuery(new DllQuery());

  // function GetXML(Assembly caller) for an assembly source
}