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