Of course I agree. We used to name the layers as follows: 1. User code (or maybe application) 2. DbLinq core 3. DbLinq vendors, because there is an IVendor interface there 4. Database drivers, because that's how everyone names them :)
So as I said, I agree. Vendors MUST NOT be tight to drivers in any way, just because of the old Oracle MS/ODP, and the new SQLite/Mono.SQLite drivers. For people who read this, Jon's ideas relate to a thread we started a few months ago, and that's probably a way to satisfy everyone (DbLinq and Mono), without leaving DbLinq custom DataContext ctors behind. Pascal. jabber/gtalk: [email protected] msn: [email protected] On Tue, Mar 10, 2009 at 04:52, Jonathan Pryor <[email protected]> wrote: > This is an appeal for standardizing nomenclature and cleaning the > architecture. > > At present, in order to do anything useful, 4 layers are involved: > > *User Code*, what the user writes, e.g. from user in db.Users.... > *DbLinq*, e.g. DataContext, what the user interacts with. > *Database Driver*, e.g. DbLinq.Sqlite.dll, responsible for generating SQL > which is sent to the provider. > *Database Provider*, e.g. System.Data.SQLite.dll, responsible for > interacting with the actual database. > > (RFC: Are these names appropriate? If not, what names should be used?) > > The benefit to this is code centralization: many databases have multiple > different providers but accept the same SQL (e.g. Mono.Data.Sqlite vs. > System.Data.SQLite, System.Data.OracleClient vs. Oracle.DataAccess, > SqlClient vs. SqlCeClient, etc.). This is even more useful to prevent > tying a driver to a particular provider version, allowing the provider to be > easily updated to later versions without modifying the driver. > > Which brings us to the problem: parts of the current DbLinq vendor > architecture tie the driver and provider layers together, specifically > DbLinq.Vendor.Implementation.Vendor.TypeToLoadData(), used by > Vendor.CreateDbConnection(). > > (Then there is the the issue mentioned at [0], in which I consider parsing > all types in all assemblies within the current AppDomain to be an > abomination, which is related to this.) > > So, in code, the problem: > > string connectionString = "DbLinqProvider=Sqlite;Data Source=Northwind.db3"; > var dc = new DataContext(connectionString); > var dcq = from p in dc.GetTable<Product>() where p.ProductName == "Pen" > select p.ProductID; > var cmd = dc.GetCommand(dcq); > Console.WriteLine("# Command Type: {0}", cmd.GetType().FullName); > // Prints "# Command Type: System.Data.SQLite.SQLiteCommand" > > This is a problem specifically for Mono, as (1) Mono will be bundling all > the drivers into System.Data.Linq.dll, (2) I want Sqlite to be supported > (simplifies testing, etc.), and (3) System.Data.SQLite.dll will *not* work > under Mono (mixed mode assembly), so I need to use Mono.Data.Sqlite.dll. > Since the current DbLinq.Sqlite.dll explicitly loads > System.Data.SQLite.dll, this causes things to break rather badly when > executing under Mono. > > The question: How do we fix this? > > First, what exactly is broken? Specifically, what is broken are the > DataContext constructors which take a string connection string parameter, > and use the connection string to deduce *both* the driver and the > provider, so this impacts only the DataContext(string) constructor. If > you use the DataContext(IDbConnection) constructor, then the original > IDbConnection instance is used for creating subsequent IDbCommandinstances, > so all is well. > > Proposed Solution: I would suggest making the connection string parameters > follow the naming scheme outlined above, and use a DbLinqDriver parameter > to specify the DbLinq driver to use (Sqlite, Oracle, etc.). I would then > use a DbLinqConnectionType parameter to be the Assembly Qualified Type > that should be used to create the IDbConnection instance. This type must > have a constructor taking a single string parameter. The current > DbLinqProvider parameter would be removed (or kept as a synonym for > DbLinqDriver, but I think down this path leads confusion.) > > This would allow the above code to work as expected while only changing the > connection string to > "DbLinqDriver=Sqlite;DbLinqConnectionType=Mono.Data.Sqlite.SqliteConnection, > Mono.Data.Sqlite; Data Source=Northwind.db3". What I'm less sure about is > whether assembly qualified type references including version > information/etc. will be valid SQL connection strings; I'll need to look > this up. > > Making this change would permit removing Vendor.GetProviderTypeName(), > thus removing the implicit dependency the driver makes on the provider. > > Thoughts? > > - Jon > [0] > http://groups.google.com/group/dblinq/browse_thread/thread/76c943f6e02735e7/4e2ea660f68e006f?lnk=raot#4e2ea660f68e006f > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
