As an OR/M Person...
time to read 3 min | 476 words

I really should learn not to read blogs at 1AM, nevertheless...

Rob Conery (SubSonic) talks about why OR/M sucks:

If you're an ORM person, ask yourself how much code you need to write to support a many to many relationship...

Just to demonstrate:

 1: [HasAndBelongsToMany(Table="UsersToRoles", ColumnKey ="`User`", ColumnRef = "Role")]
 2: public ISet<Role> Users { get { ... } set { ... } }

I also get lovely relational DB as a side benefit, but that is beside the point. Rob brings the point about "what is a DB from OO point of view" which came out in the OR/M Smackdown, I will give the same answer that I did then, if the tools does that, feel free to shot the tool.

Your goal should always be performance - don't sacrifice extra connections just to satisfy the ORM design model.

Rob, that sounds like a limitation of the tool, not the technology.

And my firstmost goal is rarely performance, actually, it is maintainability.

Think of the code you'd have to write in an ORM model to get something like a summary thread list for a forum app - you'd want to show the name of the thread, the number of replies, and the date/author of the last reply. How do you do this with ORM? The answer: lots of code.

Ha? Didn't checked it, but it is something in the order of: "select thread.Name, count(thread.Replies), r.DatePublished, r.User.Name from Thread thread, Reply r where r.Id = (select max(r.Id) from Reply where r.Thread = thread)".  Not really that much code at all, actually. Worst case scenario, I resort to something like this, which is still not a lot of code.

0 comments
Tags:

Related posts that you may find interesting:

08 Jun 2007 Influencing the direction of the .Net Framework
Community
28 Mar 2006 Appropriate Comments
Programming
26 May 2007 Sam Gentile is angry with me
Community wow