Ok. you have found the point. Given that I'm not a Microsoft fan (actually I'm a debian gnu/linux user, a plan 9 fan, but I've to work in a microsoft, now), I want to ensure here that's not my intention to demage Mono. I've plenty of reasons to hope that the Mono support for Linq over open source databases will complete as soon. And, moreover, in the next 2-3 years, I will need to build an application that I'll try to keep as compatible as possible with Mono (since some of our potential customer could require to use Linux servers!).
That said, if the linq datacontext are so hightly coupled with the SqlServer ado provider I've no chance to reach this objective as fast as I'd hope. On Fri, Mar 27, 2009 at 6:13 PM, Jonathan Pryor <[email protected]> wrote: > On Fri, 2009-03-27 at 09:31 +0100, Giacomo Tesio wrote: > > This would work untill in the System.Data.Linq.DataContext code is not > coupled with SQL server interfaces or CLR types (which I cannot know). > > There's a very simple way to see how tightly coupled DataContext is: pass a > non-SQL Server IDbConnection instance to the DataContext constructor. > > I'll save you time: it throws an exception. You can only pass SQL Server > DbConnection types to .NET's DataContext. That's how tightly coupled they > are. > > Consequently, creating a new ADO.NET <http://ado.net/> provider and > passing this to DataContext has *no *chance of working, as (you guessed > it) a new ADO.NET <http://ado.net/> provider wouldn't be supported by > DataContext. > Ok, no way. Now I've to say that I don't estimate so much the Microsoft philosophy in software design, I've learned C# few month ago, and have yet found a lot of limitations in the framework and some problem in the language (it would be pointless to list them here, but if you like we could talk about xslt 2 missing xml schema missing and undocumented features). But, the IDbConnection in the constructor interface tell me that, at least for their mocking requirements, could have lead the microsoft programmers to leave a door open. Not thinking about new versions, limited or express versions of the sqlserver ado providers which would require update to the DataContext code. And it would be really half-assed to write in the constructor an if(! connection is MicrosoftCode) throw new InvalidOperationException("Fuck you!"); It actually seem to me really strange. So, if mocking the DataContext is possible, writing such a system that from the sqlServer SQL would recreate the linq expression tree (if not a simpler one) and use it against another vendor should be possible too. That said, if it's not possible, I'll just scorn Microsoft a bit more. Nothing new! :-D Thanks for your replies, they have been clear and useful for me. And... if you've found such a dirty "if" in the Microsoft code, let me know! It will be useful when talking with my collegues (all Microsoft addicted) about the Evil! :-D Giacomo --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
