And also, working this way requires to rewrite a lof of things for each database, since the provider handles almost everything in the LINQ to SQL request.DbLinq is based on sharing as much logic as possible between vendors, so the philosophy is quite at the opposite.
Pascal. jabber/gtalk: [email protected] msn: [email protected] On Tue, Mar 3, 2009 at 16:14, Jonathan Pryor <[email protected]> wrote: > > On Mon, 2009-03-02 at 23:44 +0200, Andrus wrote: > > > I'm not really sure what the ideal solution here is, and would welcome > any > > > additional input. > > > > As I posted some time ago in this list, Linq to Sql author, Matt Warren > blog > > contains sample about replacing default MS Linq-To-Sql provider with > > other linq provider implementing provider interface. > > I assume you mean this entry: > > > http://blogs.msdn.com/mattwar/archive/2008/05/04/mocks-nix-an-extensible-linq-to-sql-datacontext.aspx > > I think it should be fairly obvious that we don't want to reimplement > Microsoft's internal interfaces, and that we should come up with a > public, well supported mechanism here. Using TransparentProxy's and > Reflection to muck about with private code is NOT the way to go. > > - 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 -~----------~----~----~----~------~----~------~--~---
