Come rimuovere l'odore da un DAL collegabile

Per coincidenza, ultimamente ho lavorato in una situazione simile - per farla breve: progettare e implementare un Estensione dell'elaborazione dei dati per SSRS che consente di aggregare i dati (per i report) provenienti da numerosi tipi di archivio: CSV o JSON che si trovano sul file system o SQL semplice (tramite System.Data.SqlClient ), o endpoint di servizio WCF, o alcune interfacce di servizio in-process (tramite riflessione standard), o alcune altre fonti / formati più strani.

Non ho IP sulla sorgente, quindi non posso rivelare più di quanto segue - se solo per una vista di 20.000 piedi, ho optato per qualcosa che assomiglia a questo:

public class DataLocatorFactory
{
    public IDataLocator GetDataLocator(string dataUri)
    {
        // After parsing our more-or-less standard or custom URI scheme,
        // use reflection over custom attribute on DataLocator classes
        // to find the IDataLocator implementation responsible for that sort
        // (read: syntax) of dataUri and instantiate it
    }
}

public interface IDataLocator
{
    IDataProvider GetDataProvider(string dataUri);
}

Quindi, più avanti:

[DataLocator("file")] // for file://<file path> URIs
public class FileDataLocator : DataLocatorBase
{
    // Can create CsvDataTableProvider, JsonDataTableProvider, etc... (all DataTable-centric)
}

[DataLocator("http")] // for http://... URLs
[DataLocator("https")]
public class WebDataLocator : DataLocatorBase
{
    // Can create WcfDataProvider, etc... (not DataTable-centric)
}

[DataLocator("sql")] // for sql://<connection name or string> URIs
// knows only about a single DataTable-centric provider, SqlDataTableProvider
public class SqlDataLocator : DataLocatorBase
{
    public override IDataProvider GetDataProvider(string dataUri)
    {
        if (string.IsNullOrEmpty(dataUri))
        {
            throw new ArgumentException("cannot be null or empty", "dataUri");
        }
        var provider = CreateProvider();
        // Here, we're just caching the DataProviders into a ConcurrentDictionary
        // (map from data URI to the provider thereof)
        // If the freshly created provider can't be bound to dataUri,
        // we just throw it away and return the provider already in cache for that dataUri;
        // of course, that means the DataProvider constructor cannot be resource acquisition- or computation-intensive,
        // but the call to Configure may be, as in WcfDataProvider creating a WS client on the fly,
        // while SqlDataTableProvider simply caches the dataUri/connection string
        // in an instance member
        if (!_dataProviders.TryAdd(dataUri, provider))
        {
            provider = _dataProviders[dataUri];
        }
        else
        {
            // A specific data locator knows how to downcast the IDataProvider into
            // its specific data provider and configure it depending on dataUri and
            // possibly from other info coming from its own configuration, or the call context, or etc
            ((SqlDataTableProvider)provider).Configure(dataUri, ...); // relies on a lock(...) { if (!_configured) { ... } } internally
        }
        return provider;
    }
}

Dove, non sorprendentemente:

public interface IDataProvider
{
    IDataOperation GetOperation(string query);
}

Quindi, più tardi:

// Clients interested in getting their data in the form of System.Data.DataTable,
// but not especially (or at all) interested in knowing how the data is being queried
// and/or from which type of store it will come from, will just go like:
//
// var locator = new DataLocatorFactory().GetDataLocator(uri); // "opaque" URI
// var provider = locator.GetDataProvider(uri);
// if (provider is IDataTableProvider)
// {
//     // Nice, I can work with that provider!
//     var operation = provider.GetOperation(query); // "opaque" query
//     var dataTable = ((IDataTableProvider)provider).GetData(operation, parameters); // "opaque" operation and params
//     // etc...
// }
// else
// {
//     // Bummer!
// }
public interface IDataTableProvider : IDataProvider
{
    DataTable GetData(IDataOperation operation, object[] parameters);
}

Dove, naturalmente:

public class SqlDataTableProvider : DataProviderBase, IDataTableProvider
{
    public override IDataOperation GetOperation(string query)
    {
        // Parse query and create our own dog food here, as, say,
        // a SqlOperation
    }

    public virtual DataTable GetData(IDataOperation operation, object[] parameters)
    {
        // Attempts to downcast operation into, say, a SqlOperation, and if satisfied,
        // interprets it accordingly to emit SQL, run it, and shape the results
        // into the promised DataTable
    }
}

Oppure, anche:

public class JsonDataTableProvider : DataProviderBase, IDataTableProvider
{
    public override IDataOperation GetOperation(string query)
    {
        // Parse query and create our own dog food here, as, say,
        // a JsonPathQuery
    }

    public virtual DataTable GetData(IDataOperation operation, object[] parameters)
    {
        // Attempts to downcast operation into, say, a JsonPathQuery, and if satisfied,
        // interprets it accordingly to delegate the job to a JsonPath implementation,
        // in some JSON parser, and shape the results into the promised DataTable
    }
}

Etc, etc

Finora, è stato ridimensionato abbastanza bene, in linea di principio, cioè (cioè, non troppo di esso).

Infine, anche se mi piacciono, non ho sentito il bisogno di introdurre alcun genere di generici, su quello (ancora / se mai).

'Spero che questo aiuti.