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
-~----------~----~----~----~------~----~------~--~---
