Thanks for the explain Jon! Ok... now I'm wondering about: - if the System.Data.Linq.DataContext would be such a base class, does we still need a Table<T> (when running in microsoft environment, obviously Mono ones still need it)? - Couldn't the IVendor be part of our DbLinq DataContext? (note that the microsoft datacontext constructors take a IDbConnection, not specific of SqlServer may this be relevant?) - why, having such DataContext, we could continue to rely on OUR sql server implementation?
Actually I've to say that what I'd like to depend on microsoft code to allow code depending on the System.Data.Linq.DataContext to be injected with DbLinq code without too much refactoring. I'm not interessed in their querybuilder, for example. I'm just thinking about the advantages of such approach. I'd really like to use Mono for our project but it is impossible, now. That said it, seem to me that such approach should move some code but I don't believe it would require to much #if nor many "new" on methods... What I'm saing is to remove some code from the DbLinq.Data.Linq.DataContext by deriving it from the System.Data.Linq.DataContext: both the DbLinq version of the System.Data.Linq.DataContext and the linq to sql one should have the same signature (and the same satellite classes). So by changing the reference of a project we would get the microsoft one or the our. We would really need to override such non virtual methods? Or we need to have such methods on our datacontext becouse it doesn't extend the System.Data.Linq.DataContext? Let me know what I'm missing, really! (also becouse I will need to explain to my boss) Giacomo On Wed, Mar 25, 2009 at 6:50 PM, Jonathan Pryor <[email protected]> wrote: > On Wed, 2009-03-25 at 18:10 +0100, Giacomo Tesio wrote: > > Actually, I'm wondering if our DataContext could extend the Linq to SQL one > even when used with a different dbms different from sql server. > > If so, the DbLinq.Data.Linq.DataContext could extend always > System.Linq.Data.DataContext. > Than the the referred DLL would make the difference. > > I don't think I understand, particularly "the referred DLL would make the > difference." Which "referred DLL"? System.Data.Linq.dll vs. DbLinq.dll? > The vendor DLL? Some other DLL? > > Furthermore, System.Data.Linq.DataContext has no (useful) virtual members, > so using it as a base class wouldn't allow us to override anything to change > behavior. > > The result is that making such a change would confer no benefits over what > we currently do. If you have e.g. DbMetal-generated source like: > > public class Northwind : DataContext ... > > The DataContext which is used is chosen at compile time *for that assembly > *, and can't be changed without recompiling the assembly. This is *identical > *to how things currently work. > > So by changing DbLinq's DataContext base class, we don't change anything > for the user (the using declarations still determine which they get), and > need to add 'new' modifiers to most/all of our public members to compile > without warnings (or with the same number of warnings as are currently > generated). > > Add in that every such 'new' modifier will require a '#if !MONO_STRICT > new #endif' block to use, and this would quickly get ugly. > > This would be important to allow the use of microsoft code, when DbLinq run > in a microsof environment, while using the Mono code when not. > > Now I get to be more selfish: this would complicate Mono. Mono can't rely > on System.Data.Linq.dll (as it's trying to implement it), which means that > the Microsoft SQL Server vendor support would be relegated to "Mono only," > thus decreasing the number of potential developers working on it (as DbLinq > won't actually be needing it). This increases the mono-specific amount of > code that I need to maintain and care about, so I (obviously) don't like the > idea. > > Now, perhaps this is "better," but it's also at the cost of making DbLinq > internals more complicated. For example, currently DbLinq needs an > IVendor implementation. If we follow the "System.Data.Linq.DataContext is > the base class" approach, we'll need to somehow determine when to actually > use our IVendor implementation vs. when we should delegate DataContext calls > to the base class. Add in that some members like > DataContext.GetTable<T>() return Table<T>, which is sealed under .NET, and > it becomes ~impossible for DbLinq's DataContext.GetTable<T>() to be > implemented in terms of .NET's DataContext.GetTable<T>() method without > also relying on .NET's Table<T> implementation (which isn't possible, as > the Table<T> constructor is internal). > > In short, I think that this approach (1) isn't workable (e.g. the "Table<T> > is sealed" issue) and (2) would make the source code uglier and more > difficult to maintain. > > - Jon > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
