Earlier quoted context omitted.
Doesn't it suck?
The first versions of EF sucked badly. But the last version is quite decent.
I'm generally not looking for a decent way to access my data quickly. Not directed at you just EF.
.NET Micro ORM Review - FluentData
11–16 of 16 posts
Re: .NET Micro ORM Review - FluentData
#12I've fallen head over heels for (Perl's) DBIx::Class and it's ability to "prefetch" joined data[1]. In short, it will populate the top level objects, as well as the items they join to from a single query (yes the DB will have to send duplicate info). I find it really convenient.
Recently I've wondered what other ORMs support this feature or something similar to it. Anyone care to comment?
[1] https://metacpan.org/module/DBIx::Class::ResultSet#prefetch
Re: .NET Micro ORM Review - FluentData
#13Earlier quoted context omitted.
No, Dapper does not suck. I too have been using Dapper at our company recently and its been an incredible boon to our db performance and code readability. Plus, if its good enough for the Stack Exchange team, then its plenty good enough for me.
The "Doesn't it suck" comment was not directed at Dapper.
Whoops! Sorry for the misunderstanding then. I was using the Hacker News+ Chrome extension and it nested the comments incorrectly...
Re: .NET Micro ORM Review - FluentData
#14Exhibit A: Yet another proof for having three obligatory pieces of software for every beginning programmer: an ORM, a blog engine and a CMS. On a more serious note, FluentData is a wheel reinvented, square. PetaPoco anyone?
After using Dapper and Massive, I have settled on PetaPoco. I've used it in multiple deployed data access layers now and have no major complaints.
Re: .NET Micro ORM Review - FluentData
#15I've fallen head over heels for (Perl's) DBIx::Class and it's ability to "prefetch" joined data[1]. In short, it will populate the top level objects, as well as the items they join to from a single query (yes the DB will have to send duplicate info). I find it really convenient. Recently I've wondered what other ORMs support this feature or something similar to it. Anyone care to comment? [1] https://metacpan.org/mod…
It sounds like what you're referring to is something I know as eager loading[1]. Most good ORMS have this e.g. Django[2], NHibernate[3], Rails[4]. The 'select N+1' problem[5] is fairly common.
[1] http://stackoverflow.com/questions/1299374/what-is-eager-loa...
[2] https://docs.djangoproject.com/en/dev/ref/models/querysets/#...
[3] http://nhforge.org/blogs/nhibernate/archive/2008/09/06/eager...
[4] http://guides.rubyonrails.org/active_record_querying.html#ea...
[5] http://stackoverflow.com/questions/97197/what-is-the-n1-sele...
Re: .NET Micro ORM Review - FluentData
#16I've fallen head over heels for (Perl's) DBIx::Class and it's ability to "prefetch" joined data[1]. In short, it will populate the top level objects, as well as the items they join to from a single query (yes the DB will have to send duplicate info). I find it really convenient. Recently I've wondered what other ORMs support this feature or something similar to it. Anyone care to comment? [1] https://metacpan.org/mod…
It sounds like what you're referring to is something I know as eager loading[1]. Most good ORMS have this e.g. Django[2], NHibernate[3], Rails[4]. The 'select N+1' problem[5] is fairly common. [1] http://stackoverflow.com/questions/1299374/what-is-eager-loa... [2] https://docs.djangoproject.com/en/dev/ref/models/querysets/#... [3] http://nhforge.org/blogs/nhibernate/archive/2008/09/06/eager... [4] http://guides.rubyo…
Ah, that's probably a much easier term to google. Part of the problem always seems to boil down to terminology. :) I figured it must be present in other ORMs, it seemed way to useful to not be pervasive.
It looks like select_related is the equivalent Django method to what I'm referring to in DBIx::Class, although prefetch_related (which you linked) looks superior in many respects. I'm fairly certain DBIx::Class allows a similar method to prefetch_related, but it may or may not be automatically done. I know it supports object caching, so it shouldn't be to hard to achieve in a few lines (but automatic is nice).
Interestingly, I don't see a way in Django to specify complex select fields to be included along with the default fields for a record. In a simple case that can be used to get a count of something, in complex cases it could be used to actually compute something on the DB to group and/or limit by (group by having). I'm probably just not familiar enough with QuerySets from this small bit of exposure to work it out.
NHibernate... That's a lot of code for something that should be simple. I imagine that's for explanatory reasons, and that much code isn't needed for most queries.