The "problem" with *Criteria is that it is physically in the NH assemly and is pretty much coupled to NH. LINQ queries are not coupled to any LinqTo* provider, they are abstract. If NH just separated criterias into independent project, like Castle has DP out of MK/W, that could be better. But now, when we have LINQ it makes more sense to move to it. We are just not there yet. What Ken does with IFilter is just abstracting NHcriterias by hand.
On Wed, Nov 12, 2008 at 7:36 PM, Nathan Stott <[EMAIL PROTECTED]> wrote: > DetachedCriteria are not technically any more NH specific than Linq queries > are Linq to Sql specific. That's the justification I've used for allowing > my controllers use DetachedCriteria and it has greatly simplified my life. > Trying to fight it was causing me to make a lot of silly methods like > "FindUsersByBirthdayAndPartialFirstName" > > > On Wed, Nov 12, 2008 at 10:30 AM, Ken Egozi <[EMAIL PROTECTED]> wrote: > >> same here, with a different reason though. >> >> IRepository is a domain term, and as such should be ignorant of NH, >> specifically DetachedCriteria. >> >> so my IRepo.Find will accept an IFilter, and on the implementation layer >> I'd translate that into a DC (or namedQuery is the filter is simple enough), >> and forward to call either to the ISession directly, or to rhino's IRepo >> > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Rhino Tools Dev" 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/rhino-tools-dev?hl=en -~----------~----~----~----~------~----~------~--~---
