Not really into political arguments. We have code that still binds to DataTables and DataSets and have market for this too. Plus, it's not us that make this decision, but our customers - we want to maximize our potential market and it's working fine for us so far.
Anyway, I've changed our data code to work-around this NHibernate understanding of LINQ. Thanks a lot for the suggestions. If you guys encounter problems with out products with NHibernate, please let us know - we want to support NHibernate as much as possible. PS. http://www.west-wind.com/weblog/posts/134706.aspx Cheers, R. On Jul 31, 5:44 pm, Fabio Maulo <[email protected]> wrote: > WOW!!! Create OO but not strongly-typed queries at runtime... that's coooool > Man!!! > I never heard about it before. > > On Sat, Jul 31, 2010 at 11:30 AM, Rumen Stankov > <[email protected]>wrote: > > > > > > > Hello, > > > Well, you can say it that way, yes. But it's a bit more complicated > > than that. While typically most people will strongly type the query, > > many others will prefer just anything that they don't know. Hence we > > decided to use that. So as a UI provider that binds to anything (on > > theory), we decided this would be good: > > >http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1... > > > Just wanted to share, since it might help a bit. I believe you could > > be interested in the details. > > > Cheers, > > R. > > > On Jul 31, 5:21 pm, Fabio Maulo <[email protected]> wrote: > > > The Dynamic-LINQ is that using strings instead of strongly-typed ? > > > > On Sat, Jul 31, 2010 at 11:18 AM, Rumen Stankov <[email protected] > > >wrote: > > > > > Just a quick update, if this helps - we are actually using the Dynamic > > > > LINQ Library (we decided we need support for anonymous types) > > > >http://msdn.microsoft.com/en-us/vcsharp/bb894665.aspx > > > > > and there is no ToList() there. Not a showstopper, I've already > > > > implemented an Extension Method that does something similar, but just > > > > decided to share since it might be interesting for you. > > > > > On Jul 23, 5:35 pm, Fabio Maulo <[email protected]> wrote: > > > > > NH has and will have bugs as any others software. > > > > > That is what everybody should assume. > > > > > > NH is not the best persistence framework in .NET ecosystem, it is > > "only" > > > > the > > > > > most used, the most powerful, the most flexible so far. > > > > > If a user can find something else that fit his needs, there is no > > > > problem. > > > > > We can do our best but "make everybody happy" is not one of our > > target. > > > > > > On Fri, Jul 23, 2010 at 11:23 AM, Frans Bouma <[email protected]> wrote: > > > > > > > and everyone should think that NH is not the place where ask the > > > > solution > > > > > > of > > > > > > > all evils. > > > > > > > I don't think that's the point. The point is: > > > > > > 1) if NH says it contains a working Linq provider, a user can only > > > > assume > > > > > > it > > > > > > indeed works. If it doesn't, the user can only conclude: the linq > > > > provider > > > > > > doesn't work or has a bug. If a feature hasn't been implemented, > > the > > > > linq > > > > > > provider is thus incomplete. Unfortunately, an incomplete linq > > provider > > > > is > > > > > > more a burden than a blessing. > > > > > > 2) if NH wants to be the best o/r mapper out there, a working linq > > > > provider > > > > > > is essential. The main reason is that more and more people will > > learn > > > > about > > > > > > o/r mapping and learn Linq, how it works etc. as there are many > > books, > > > > > > articles written for EF and Linq to SQL and linq itself. If these > > > > people > > > > > > can't use their knowledge with NH, the barrier to accept it as the > > best > > > > > > there is is higher. > > > > > > > FB > > > > > > > > On Fri, Jul 23, 2010 at 10:05 AM, Roy Jacobs < > > [email protected]> > > > > > > wrote: > > > > > > > > > > The 'ToList()' workaround is silly really, you don't > > want > > > > to > > > > > > > fetch > > > > > > > > > all data to do an aggregate in-memory > > > > > > > > > eh?!??!?? > > > > > > > > NH ha to workaround RDBMS issue. > > > > > > > > NH have to work around to commercial companies visual > > > > components. > > > > > > > > I think Frans' point is that even though the Count() seems > > > > > > redundant > > > > > > > after a Take(), it's still a completely valid LINQ query. > > > > > > > > Certainly, when one is directly writing the LINQ query, > > it's > > > > not a > > > > > > > problem to simply add a ToList(), but when working with > > > > third-party > > > > > > > components like the original poster is, it's not always > > > > reasonable > > > > > > to > > > > > > > expect them to be able to modify the query. > > > > > > > > Having said that, I think everyone is aware how complex > > writing > > > > a > > > > > > > LINQ > > > > > > > provider is :) > > > > > > > > -- > > > > > > > Roy > > > > > > > > -- > > > > > > > Fabio Maulo > > > > > > -- > > > > > Fabio Maulo > > > > -- > > > Fabio Maulo > > -- > Fabio Maulo
