.NET Micro ORM Review - FluentData

http://www.codecognition.org/2013/03/micro-orm-reviews-fluentdata.html

by ale55andro • 13 years ago

12 14 13 years ago

codecognition.org

dhgfhf• 13 years ago

What's the point of this when you have EF?

anton_gogolev2• 13 years ago

Doesn't it suck?

Griever2• 13 years ago

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.

adolfojp• 13 years ago

The first versions of EF sucked badly. But the last version is quite decent.

ed_blackburn• 13 years ago

EF is a massive 'enterprise' codebase aimed predominately at SQL Server. If you don't need all the features ORMs like EF (or NH for that matter) offer (with all their associated config) then a micro-orm maybe better suited.

Dapper has been very useful at my current gig and more innovation in that space the better. Okay these micro-ORMs lack fundamentals like identity maps and caching but do you always need these features?

Inertia is dangerous.

anton_gogolev2• 13 years ago

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

atwebb2• 13 years ago

There are several micros (I'm sure you know) but I love the micro, micro approach of Peta. I'll admit that up until recently, I've always setup my own classes with data myself. Looking back on projects, it actually hasn't been that bad. These are medium sized applications and, yes, setting up properties is super annoying and can take a while but, in retrospect, it hasn't cost me that much really, I don't see how I could save more than a few hours with an ORM and I have 100% control over my database interactions, code separation, complete knowledge about exactly what it is doing, and a fast application.

I like Peta because it's the smallest most minimal ORM I've found. I can grasp most of what it's doing after little work with it and it's fast enough for me though I'm definitely not pushing it too hard.

the_rara_avis• 13 years ago

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.

kbenson2• 13 years ago

I'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

damagednoob• 13 years ago

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

kbenson2• 13 years ago

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.

.NET Micro ORM Review - FluentData

Related Stories