ERRATA CORRIGE: - why, having such DataContext, we could *NOT* continue to rely on OUR sql server implementation?
In other words: couldn't we derive the linq to sql datacontext without eventually using it's sql server specific code? Giacomo On Wed, Mar 25, 2009 at 9:13 PM, Giacomo Tesio <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
