More views from an OR/M person

time to read 3 min | 444 words

Rob Conery responded in a comment to my previous post, which includes some interesting points of discussion.

I think, in your example above, that it's only fair to also include the "under the hood" stuff you need to map these associations. In other words - I count the XML mapping as line of code too :) since this is code and it does have to be maintained.

Okay, no problem, I am using [ActiveRecord] attributes, so that puts me about 1-2 lines of attributes per property + 1 to 2 lines of code per entity. You can see the mapping in the first example that I have posted.

Your code sample RE the forum bits is a great exhibition of the power of the NHibernate query tool, but at the same time it reminds me of LINQ - why not just write SQL? I understand that in many cases you'd want to abstract that stuff away in case you change DBs

I am not using OR/M because I want to keep the DB abstracted. I am using an OR/M because it frees me from a lot of persistence related concerns and allows me to concentrate on the domain and the business problems.

In terms of perf vs maintainability - I really think this needs more consideration. To be honest, who's the app for anyway? The dev team or the client?

Only in the most extreme cases, and even then, after you have measured. Because the client is king, you want to ensure that you can keep giving value from the code that you have written. I am not seeing a problem between maintainable applications and performant applications, on the contrary. Maintainable applications give you a lot more flexibility in performance tuning.

Less lines of code - more direct: (SELECT * FROM MyView).

Also, less performant, no?

BTW, why did you bring MySQL to the discussion?

Tweet Share Share 7 comments

Tags:

O/R Mappers

Comments

05 Jun 2007
11:53 AM

Stefan Wenig

Hey, that fight was more fun when you did it with Ted Neward! ORM is only for simple apps? If you want to impress us, pick a harder fight ;-)

05 Jun 2007
15:35 PM

Arne Claassen

I've seen too much one off code written in the name of "performance" and all it did was perform well for the v1.0 edge case, once v1.1 with all new business requirements rolled around, it turned into a slow mess of patches or required a rewrite. With an OR/M I can always tune for performance, but I can't patch for maintainability.

Sure there are web companies that are at the extreme end, but even though every ecom site wants to have traffic like Paypal, close to none will ever get it and in the meantime a more maintainable model lets them adapt their business model more quickly when widget X falls out of favor.

Finally, and maybe the most important reason for ease of maintainability that you usually only see once you're not a lone gun but responsible for a team is that I can buy more and bigger hardware a whole lot more simply and cheaply than I can hire another good engineer that can quickly grok a large custom codebase.

05 Jun 2007
19:36 PM

Rob Conery

I am not using OR/M because I want to keep the DB abstracted. I am using an OR/M because it frees me from a lot of persistence related concerns and allows me to concentrate on the domain and the business problems.<<<

Fair enough :). I think you and I think alike in this regard - after all SubSonic is a large part ORM. It's in the extreme, when you throw more and more code at a complex issue rather than use a simpler approach (like a view or SP) that the ORM model breaks. I'm sure you've run into this - you must have.

Overall, If you document what you're doing, is there really a question in terms of maintainability?

I've seen too much one off code written in the name of "performance" and all it did was perform well for the v1.0 edge case, once v1.1 with all new business requirements rolled around, it turned into a slow mess of patches or required a rewrite<<<

Example please? And I would offer to you that I've seen ORM tools completely written out of many applications because of perf issues, supportability (no one knew how to use them) and, oddly enough, maintenance nightmares as the app grew.I know that any tool can be abused - that's my point entirely isn't it.

Finally, and maybe the most important reason for ease of maintainability .... is that I can buy more and bigger hardware a whole lot more simply and cheaply than I can hire another good engineer that can quickly grok a large custom codebase<<<

I apologize if this comes off wrong, but if you worked at the companies I worked for you'd be fired for this comment. "Just buy more hardware so I can code this way". This line of thinking is sooooo completely dev-centric that all I can do is wonder "did he really just say that". I truly don't want to offend - so I'll assume I misunderstood you. I'll also offer that my client list includes PayPal, eBay, SBC, Microsoft, Pioneer, and KLA-Tencor. I don't come at this from a "lone gun" perspective and these guys are very, very serious about perf.

I'll add one final thing - you guys are assuming that all "good engineers" out there know and understand NHibernate. In your view does knowledge of NHibernate factor into maintenance? And if not, how can this NOT be construed as a "one off" position?

BTW, why did you bring MySQL to the discussion<<<

Only to point out that MySQL is a system that ORM fits well into. Some of the engines don't support DRI, it doesn't use views, and earlier versions don't have SPs. In that case, ORM is a fine choice (as used by the Rails guys).

05 Jun 2007
20:18 PM

Jesse

Well really if were talking strictly performance here then we should just be using data readers directly in our UI. They perform the best and theres no manipulation from data source to object.

If we all thought this way then our apps would perform great but would be a maintenance nightmare.

Theres a balance of maintainability vs performance. You should do the the thing that performs at an acceptable level and is the most maintainable. As soon as you have to start really tweaking for performance then your app becomes less maintainable and harder to understand.

ORM's are so much more than just a pass through DAL. You cant really compare an ORM to a simple later that translates data readers into collections of objects.

Once an ORM is not performant enough for your requirements then you need to go down other paths. But I think a good ORM has totally acceptable performance for the majority of applications out there.

06 Jun 2007
00:45 AM

Arne Claassen

I apologize if this comes off wrong, but if you worked at the companies I worked for you'd be fired for this comment. "Just buy more hardware so I can code this way". <<

Well, put that way, you would be right, but you are using a bit of hyperbole there. In all honesty, the moment we said "ooh, let's use .Net", we might as well have said "Just buy more hardware so I can code this way" and while you're at it throw in more RAM! Using an ORM is not the worst crime against performance ever committed. In my experience the scenario is more along the lines of "I need 5 servers in my farm vs. for 3, but I'll need only 1 engineer to maintain the DB API instead of 2" and the "more hardware" option wins without a career ending incident for the decision maker.

I don't assume that "good engineers" know NHibernate. My comments aren't so much about NHibernate and neither am I attacking SubSonic, btw. I'm talking about performance vs. maintainabiltiy and what I am trying to say is that standardizing on documented tools with acceptance outside your organization can drastically reduce the learning curve for your engineers.

To me a good ORM let's you create a clear object model and it does a lot of the legwork that is standard plumbing. Not having to recreate that each time is a good thing. I know there is performance overhead to that and in certain situations that's not acceptable. However most situations I've dealt with the expense has been worth it for the object model I got in exchange.

06 Jun 2007
03:10 AM

Evan

Regarding this very same topic, I've left a few thoughts on putting "simple business logic" into the database on my blog..

http://www.evanhoff.com/archive/2007/06/05/19.aspx

06 Jun 2007
07:05 AM

goodwill

I apologize if this comes off wrong, but if you worked at the companies I worked for you'd be fired for this comment. "Just buy more hardware so I can code this way

Time to learn C and Linux. I am sure if I build an app with a bare functional kernel + c based service it would perform best. Could any explain how did the slowest language- Java- climb up the latter at #1 position of TIOBE most used language?

I have written 2 more articles on my blog, I think its more or less insightful for people who came from non-ORM setup:

http://bugthis.blogspot.com/2007/06/following-up-ayendes-post-regarding-orm.html

http://bugthis.blogspot.com/2007/06/i-decided-to-crank-up-part-2-before-i.html

Comment preview

Comments have been closed on this topic.

Markdown turns plain text formatting into fancy HTML formatting.

Phrase Emphasis

*italic*   **bold**
_italic_   __bold__

Links

Inline:

An [example](http://url.com/ "Title")

Reference-style labels (titles are optional):

An [example][id]. Then, anywhere
else in the doc, define the link:
  [id]: http://example.com/  "Title"

Images

Inline (titles are optional):

![alt text](/path/img.jpg "Title")

Reference-style:

![alt text][id]
[id]: /url/to/img.jpg "Title"

Headers

Setext-style:

Header 1
========
Header 2
--------

atx-style (closing #'s are optional):

# Header 1 #
## Header 2 ##
###### Header 6

Lists

Ordered, without paragraphs:

1.  Foo
2.  Bar

Unordered, with paragraphs:

*   A list item.
    With multiple paragraphs.
*   Bar

You can nest them:

*   Abacus
    * answer
*   Bubbles
    1.  bunk
    2.  bupkis
        * BELITTLER
    3. burper
*   Cunning

Blockquotes

> Email-style angle brackets
> are used for blockquotes.
> > And, they can be nested.
> #### Headers in blockquotes
> 
> * You can quote a list.
> * Etc.

Horizontal Rules

Three or more dashes or asterisks:

---
* * *
- - - -

Manual Line Breaks

End a line with two or more spaces:

Roses are red,   
Violets are blue.

Fenced Code Blocks

Code blocks delimited by 3 or more backticks or tildas:

```
This is a preformatted
code block
```

Header IDs

Set the id of headings with {#<id>} at end of heading line:

## My Heading {#myheading}

Tables

Fruit    |Color
---------|----------
Apples   |Red
Pears	 |Green
Bananas  |Yellow

Definition Lists

Term 1
: Definition 1
Term 2
: Definition 2

Footnotes

Body text with a footnote [^1]
[^1]: Footnote text here

Abbreviations

MDD <- will have title
*[MDD]: MarkdownDeep

Oren Eini

Oren Eini

CEO of RavenDB