When I went to similar issue, I've opted for extesion (see DataContext.GetIDbCommand()).
We could add some DataContext method to enable the building of such parametric queries allowing the user to use them as he like. That said, we (at my company) really need DbLinq as a Linq to Sql replacement/improvement. I agree that we should not ALWAYS mimic Linq to Sql, we could do some things better allowing more use pattern. We are not Microsoft, we could assume a better use base that would appreciate having different possible ways to do things and is able to learn how to choose between them (thanks Microsoft for keeping Visual Basic closed source! :-D). But since having a good, strongly typed, Data Access Layer (including a powerfull QueryObject) is far better than having to manipulate string queries, I think we should continue with our design strategy. BTW, I'd like to know how Mono users, seing DbLinq under System.Data.Linq should access such DbLinq's improvement over the Linq to Sql code base. Giacomo On Wed, Jun 17, 2009 at 8:25 AM, greyman <[email protected]> wrote: > > On Jun 17, 1:49 pm, Jonathan Pryor <[email protected]> wrote: > > > > I'm still not sure how to fix it though. :-/ I'm philosophically > > opposed to a global QueryCache (global data is bad!), and a > > per-DataContext QueryCache doesn't make lots of sense. > > > > I thus see two solutions: > > > > 1. Figure out why query creation takes so long, and speed it up. (The > > same should be done for the constructor, for that matter.) > > > > 2. Use a QueryCache, but instead of making it an internal implementation > > detail -- meaning the user has ~no control over its lifetime -- make it > > something the user can control. This could be done by making QueryCache > > a public type, and adding a DataContext.QueryCache property. If the > > user wants to use a cache, they can create a global cache and provide it > > to the DataContext as part of their initialization steps. > > > > This gives control of the cache to the user, allowing them to easily > > monitor size and provide cache policy, without creating an > > internal-to-DbLinq-memory-leak-in-waiting. > > > > One thing that I have thought about a few times over the past month as > I have to up to speed on DbLinq is whether the library should be doing > less rather than more. The two really cool things DbLinq can do are > firstly translate LINQ expressions to SQL for a variety of databases > and secondly generate the SQL for CRUD operations on .Net classes also > for a variety of databases. Would it be better if DbLinq rather than > taking control of the whole database operation was used to generate > the parameterised SQL. > > I know that doesn't fit with the whole Linq2SQL API DbLinq is triving > towards and I'm not even sure if there it's entirely feasible or even > a good idea. I just thought I'd throw the idea out there as it does > solve a number of issues such as DbLinq having to worry about query > caching and of course my favourite issue database connection pool > usage. > > Regards, > > Aaron > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
