Refactor backends

[stuarta0]

Move behaviour of IParameter ToSqlString into dbqf.Sql library (as well as SqlString class itself). Inherit every existing concrete IParameter (e.g. LikeParameter -> SqlLikeParameter), and implement the ToSqlString (possibly with another ISqlParameter interface too, which defines this).

All the ParameterBuilder logic should probably move into the dbqf.Sql library, leaving interfaces behind in the core (maybe?). Or copies, depends on whether having ParameterBuilders that make vanilla IParameters is even worth it? (i.e. we'll always need a backend of some kind, so the implementetions will usually end up there).

Even the behaviour of Subject.SourceSQL and .Sql(string) should probably move into dbqf.Sql as they have no bearing on an ORM implementation. Check references on these properties to see how often they are actually referenced (if only in the SQL and Standalone projects then we're all good).

Make an ISqlGenerator interface based on the dbqf.Sql SqlGenerator, and another for the ISqlListGenerator.

Make a dbqf.MsAccess version, which references core and dbqf.Sql as we'll be wanting to use the IParameter types defined in dbqf.Sql (maybe). Create concrete implementations of SqlGenerator with MsAccess-specific SQL structure.

For EF, make a dbqf.EF project, with Configuration, Subject and Field types that bind to property info (or something) that defines mapping within EF. Either use the vanilla IParameter implementation in core (if FieldPath is enough), or inherit and provide further functionality for building LINQ expression trees for each IParameter (more likely). Rather than have an SqlGenerator class, we'll need to determine what kind of class is required to take the LINQ expression trees from the parameters and combine them together and execute via EF. Remembering it is possible to run direct SQL through EF so this is an option.

Standalone should have a factory for generating all required objects for querying and retrieving results. Instead of ISqlResults, it should probably be more like BackendFactory which has methods for getting an ISqlGenerator, ISqlListGenerator, and the concrete DbConnection/DbCommand objects. Or, we just encapsulate all the logic and don't even expose generators or connections, just have an IDbService which only has:

DataTable GetResults(FieldPath[], IParameter)
List<string> GetList(IField)

Then we can have a factory class that returns an IDbService based on string key for the list of connections in a configuration; "SqlClient", "SQLite", and "MsAccess". In fact the connection object in the configuration should really just serialise the concrete type (e.g. rather than object Connection, have an SqlClientConnection which has ConnectionString, an SQLiteConnection which has Filename, etc.).

[stuarta0]

Implement this: http://weblogs.asp.net/cazzu/62141

[stuarta0]

Closed in 2c011050c53a8128b01877979f2ebc2713f408f6