Oh my, you're touching something here... I think that depends on what exactly you're talking about.
Converting LINQ to SQL is hard, no doubt. Mostly that's because of the (invisible) transformation that C# does in order to get executable C#. Making that easier is all re-linq was about, and while this was a heap of work, I'd consider that problem solved now. Then there's the problem of translating LINQ queries that do something that just can't be done as easily in SQL. There's a lot of conceptual mapping going on, we have to think about stuff like eager fetching, n +1 etc. For these cases I'd argue that a seasoned developer would know which LINQ queries to avoid in order to get efficient SQL. But in other cases, LINQ just lets you create simple and powerful queries that would be bloated and redundant in SQL, so there's an up-side to it as well. It's just so much more expressive. (But I sure wish there was a way to make intellisense reflect that a provider doesn't support some query method or another. Unfortunately, you'd have to throw IQueryable out to get there.) But if you know what kind of SQL query you want, that's usually easy to do in LINQ. The _implementation_ of LINQ is clearly biased towards in-memory execution, and going to SQL is not half as nice (from a provider perspective, that is). However, from a user perspective, LINQ was _designed_ from the beginning to be translated to SQL eventually. I for one wouldn't want to go back to a specific embedded-string query language of any kind. Cheers, Stefan On Jun 18, 6:05 pm, Fabio Maulo <[email protected]> wrote: > and the bad thing is that LINQ was implemented to query objects in RAM and > to convert it to an efficient SQL is not a joke. > For sure you can say "well... that is a problem of the provider"... > With NH you have a good probability to have the issue fixed... perhaps... > But with EF you will need to wait the next release. > btw... the conversion from LINQ in RAM to efficient SQL believe me that is > not a joke when you have complex queries involving many relations/methods. > Even with HQL you can express a "domain concept"... the difference is that > HQL was designed specifically to be translated in an efficient SQL. > > You have to release your application tomorrow early in the morning, you > can't wait us. > > 2010/6/18 Oskar Berggren <[email protected]> > > > > > > > 2010/6/18 Fabio Maulo <[email protected]>: > > > You can write Specifications/QueryObject using interfaces and having a > > > Specification/QueryObject factory... and again your high layers does not > > > need to be wired to NH. > > > Absolutely. The good thing with the linq variety is that they can > > express a domain concept, and have use beyond database queries, since > > they don't depend on NH or any other database access layer. > > > /Oskar > > > > There is a constant on all these years... IT change day by day and > > rewrite a > > > whole app is not so funny. > > > We can write good app. just warring about our business and without need > > to > > > be wired to a specific technology for DataAccess. > > > > 2010/6/18 Oskar Berggren <[email protected]> > > > >> Might add a bit of Specification pattern to that. At least for those > > >> queries that can be written with linq. > > > >> /Oskar > > > >> 2010/6/18 Fabio Maulo <[email protected]>: > > >> > My advise: > > >> > 1) IRepository (no queriable) > > >> > 2) concrete Repository implementation queriable (implements > > IQueriable) > > >> > 3) inside the Repository impl. you are in the "safe area" (the other > > >> > part of > > >> > the app. does not know NH) > > >> > 4) depending on the query you can use: LINQ (new in > > >> > NH3), HQL, QueryOver, > > >> > SQL > > >> > Do you remember that old times when people said "to write SQL > > >> > incrustated in > > >> > the code, everywhere, is a really bad practices" ? > > >> > well... > > >> > which is the difference with a LINQ sentence to go to persistence ? > > >> > The Repository/DAO is the responsible of DataAccess and one of its > > most > > >> > important responsibility is the construction of the query. > > >> > If you move this responsibility out side the Repository/DAO impl you > > >> > will > > >> > have the same identical issue than write SQL everywhere. > > >> > On Fri, Jun 18, 2010 at 2:53 AM, Tomasz Modelski (IDev) > > >> > <[email protected]> wrote: > > > >> >> I'm using NH trunk version, rev. 4790 from 12.04.2010 on my > > production > > >> >> application, application is still under heavy development and > > >> >> deployment (we are working something like agile iterations). > > >> >> We are forced to use all NH query providers :-). > > > >> >> There are some situations where old LinqToNH works better then new > > >> >> one :-) > > >> >> there are some situations where new LingToNh works better then old > > >> >> one :-). > > >> >> 'Hidden powers' are in new QueryOver api. It's criteria api in Linq/ > > >> >> labda style. It works very good, almost error free, but still have > > >> >> limitations. > > >> >> And hql is the last ultimate solution for all weird raporting queries > > >> >> with grouping, HAVING, IN / NOT IN etc. > > > >> >> It would be nice to hear some status report from NH team, maybe some > > >> >> blog entry. > > > >> >> Maybe someone from LinqToNH team could make some page / blog entry > > >> >> with examples of working & not working queries using new LinqToNH and > > >> >> QueryOver. > > >> >> It would be very helpfull. > > > >> >> regards, Tomasz Modelski. > > > >> >> ps. lately, I steadily check the > > >> >>http://sourceforge.net/projects/nhibernate/develop > > >> >> page to see if there are some major Linq improvements and when it's > > >> >> worth to get & compile latest trunk. > > > >> >> On 18 Cze, 01:09, Jeffry Morris <[email protected]> wrote: > > >> >> > Yes, by my usage scenarios have been very simple to date. Simple > > >> >> > joins > > >> >> > and > > >> >> > projections. I can say that I already surpassed some of the > > >> >> > limitations > > >> >> > in > > >> >> > the older provider, which couldn't even do a join. > > > >> >> > By this time next month, I'll know more... > > > >> >> > On Thu, Jun 17, 2010 at 3:49 PM, Craig van Nieuwkerk > > >> >> > <[email protected]>wrote: > > > >> >> > > Have you been able to use Linq almost exclusively for writing > > >> >> > > queries > > >> >> > > now, or do you still go back to ICriteria and HQL occasionally? > > > >> >> > > On Fri, Jun 18, 2010 at 7:00 AM, Jeffry Morris > > >> >> > > <[email protected]> > > >> >> > > wrote: > > >> >> > > > It's merged with the trunk for NHibernate 3...I have been using > > >> >> > > > it > > >> >> > > > for a > > >> >> > > few > > >> >> > > > weeks and I am very happy :) > > > >> >> > > -- > > >> >> > > You received this message because you are subscribed to the > > Google > > >> >> > > Groups > > >> >> > > "nhusers" group. > > >> >> > > To post to this group, send email to [email protected]. > > >> >> > > To unsubscribe from this group, send email to > > > >> >> > > [email protected]<nhusers%[email protected]> > > <nhusers%[email protected]<nhusers%252bunsubscr...@googlegroups.com> > > > > > >> >> > > . > > >> >> > > For more options, visit this group at > > >> >> > >http://groups.google.com/group/nhusers?hl=en.-Ukryj cytowany > > tekst > > >> >> > > - > > > >> >> > - Pokaż cytowany tekst - > > > >> >> -- > > >> >> You received this message because you are subscribed to the Google > > >> >> Groups > > >> >> "nhusers" group. > > >> >> To post to this group, send email to [email protected]. > > >> >> To unsubscribe from this group, send email to > > >> >> [email protected]<nhusers%[email protected]> > > . > > >> >> For more options, visit this group at > > >> >>http://groups.google.com/group/nhusers?hl=en. > > > >> > -- > > >> > Fabio Maulo > > > >> > -- > > >> > You received this message because you are subscribed to the Google > > >> > Groups > > >> > "nhusers" group. > > >> > To post to this group, send email to [email protected]. > > >> > To unsubscribe from this group, send email to > > >> > [email protected]<nhusers%[email protected]> > > . > > >> > For more options, visit this group at > > >> >http://groups.google.com/group/nhusers?hl=en. > > > >> -- > > >> You received this message because you are subscribed to the Google > > Groups > > >> "nhusers" group. > > >> To post to this group, send email to [email protected]. > > >> To unsubscribe from this group, send email to > > >> [email protected]<nhusers%[email protected]> > > . > > >> For more options, visit this group at > > >>http://groups.google.com/group/nhusers?hl=en. > > > > -- > > > Fabio Maulo > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "nhusers" group. > > > To post to this group, send email to [email protected]. > > > To unsubscribe from this group, send email to > > > [email protected]<nhusers%[email protected]> > > . > > > For more options, visit this group at > > >http://groups.google.com/group/nhusers?hl=en. > > > -- > > You received this message because you are subscribed to the Google Groups > > "nhusers" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]<nhusers%[email protected]> > > . > > For more options, visit this group at > >http://groups.google.com/group/nhusers?hl=en. > > -- > Fabio Maulo- Hide quoted text - > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "nhusers" 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/nhusers?hl=en.
