this is indeed pretty cool, but i don't think anything is going to reduce the 'give us LINQ support' chants :)
On Thu, Jan 8, 2009 at 2:38 PM, Stephen Bohlen <[email protected]> wrote: > Agreed. That's why I said I'm 100% in favor of this effort -- was just > considering whether or not this would have any impact on the 'gimme LINQ' > refrain :) > > ------------------------------ > *From*: "Fabio Maulo" > *Date*: Thu, 8 Jan 2009 10:23:12 -0300 > *To*: <[email protected]> > *Subject*: [nhibernate-development] Re: Type safe criteria > Ok Steve but in this case (NH-lambda-extension) the target is pretty clear > : Completely avoid strings > 2009/1/8 Stephen Bohlen <[email protected]> > >> First, I'm all for this. Over the recent past, others (including myself) >> have tinkered with variations on just such an approach... >> >> >> http://www.kowitz.net/archive/2008/08/17/what-would-nhibernate-icriteria-look-like-in-.net-3.5.aspx >> >> >> http://bugsquash.blogspot.com/2008/03/strongly-typed-nhibernate-criteria-with.html >> >> >> http://unhandled-exceptions.com/blog/index.php/2008/11/22/the-continuing-quest-for-death-of-string-literals-in-my-code/ >> >> ...with some of us going farther than others (e.g., my musing never lead >> to anything fully-featured, but instead just languished as a quick spike on >> my HD). >> >> It sort of seems to me like there are two (largely orthogonal) concerns >> here: >> >> 1) remove the dependence on string-literals in ICriterion queries >> >> 2) LINQ provider for NH >> >> #1 is IMHO an entirely worthwhile goal in its own right -- clearly the >> less magic, refactor-proof strings there are the better off we all are. I >> would guess that there are some issues with how this would find its way into >> the NH trunk since presently NH 2.1 has a publicly-stated desire to continue >> to target Fx 2.0 and we need Fx 3.x for lambda support AFAIK (an >> implementation detail that could be solved by introducing some kind of >> NH3xExtensions.dll assembly or something similar to that, so not a >> deal-breaker by any means of course but rather just an acknowledgement of >> some add'l complexity). >> >> But as for #2, to me this gets to the heart of WHY people would want a >> LINQ provider -- if its to get intellisense during the construction of >> queries, then I think this would definitely help alleviate some of that >> pressure as you suggest. But if its so that people already familiar with >> LINQ can move laterally from their present DAL-of-choice to NH, then I don't >> entirely see how this would help reduce that pressure (since knowing LINQ >> wouldn't ease the coming-to-NH learning curve). >> >> Maybe its worth re-evaluating WHERE the frequent requests for LINQ support >> are coming from to try to futher investigate their 'motives/goals' which >> might help us better understand the relative value of this 'alternate' >> approach...? Is is people who ALREADY know NH and are looking for a more >> refactor-friendly way to construct queries or is it from non-NH-users who >> are looking to flatten their learning curve when approaching NH? Or is it >> from present NH-users who are looking to spread it to the rest of their >> team/company/whatever and are considering that LINQ2NH would make that >> process easier --? If we knew better their goals, we might be better able >> to evaluate the effectiveness of pursuing this 'intermediate' step. >> >> FWIW, I would consider that this is (or something very much like it) would >> be a valuable introduction to NH regardless of whether it materially reduces >> the calls for a complete LINQ2NH provider -- clearly its something that >> myself and others (including the initially-referenced poster) have been >> thinking about for some time. >> >> Other thoughts? >> >> -Steve B. >> >> >> On Thu, Jan 8, 2009 at 4:52 AM, Ayende Rahien <[email protected]> wrote: >> >>> This is really interesting: >>> >>> >>> http://nhforge.org/blogs/nhibernate/archive/2009/01/07/typesafe-icriteria-using-lambda-expressions.aspx >>> >>> Expanding the syntax a bit, we can use: >>> >>> session.CreateCriteria<Person>() >>> .SetFetchMode(p => p.PersonDetail, FetchMode.Eager) >>> .SetLockMode(LockMode.Upgrade) >>> .Add(p=>p.Name.Like("foo")) >>> .List(); >>> >>> That would remove a lot of the pressure to build a full fledged linq >>> provider. >>> And it seems like it is much easier to do. >>> >>> Thoughts? >>> >> >> > > > -- > Fabio Maulo > -- Davy Brion http://davybrion.com
