Developing for Scalable Applications
time to read 6 min | 1038 words

Evan Hoff has an eye opening post about the results of putting simple business logic in the database. Go read it, now.

Now, after you have read that, let me continue with Rob's reply to my previous post:

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.

I disagree in part, since it all depends on what do you define as extreme. Using OR/M opens new levels of extremeness with regards to the DB and queries. A few days ago I spend a few hours writing a query using NHibernate that I would never ever write in SQL, because it would be so much work to handle that. Obviously there are things that the DB does best, and for that, I have other options, including views or SP, but I use those through the OR/M, so I maintain my domain.

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

Absolutely. I can give you well documented code that it an absolute nightmare to develop with. It may be performant, but it wouldn't let you do anything with it.

Case in point, a coworker had decides that he wants to "save" page load times by not using user controls in a WebForms application. He still needed to generate dynamic HTML. He put the dynamic HTML in a resource file, read it into a static variable, and then built the HTML using string.Format().

There is a chance that it is more performant solution that just using user controls, and there was a clear line of reasoning leading to this behavior, but the maintainability concerns were:

  • Non standard way of doing something, completely threw me off when I looked at the page.
  • Ugly code that I couldn't understand.
  • Presentation logic & HTML Generation are two separate concerns that were mixed together
  • You had to restart the application if you wanted to change the HTML in the resource file (static variable for caching)
  • Guess what happens for other cultures?
  • No syntax highlighting or designer support for the HTML

This is only from a few minutes of thinking about it. I have not profiled the differences, but I believe that they are minute if any, but even if it had significant advantage, the maintainability concerns are simply too important. I'll throw a cache at the page and still be faster than anything hand optimized can get to.

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

You can use any tool badly, so I can't really comment on this unless I have more information. Perf issues are not inherent to OR/M by no means, but it is certainly possible to use OR/M to create performance issues. The same is true for maintainability in OR/M, it is not a given if you use OR/M, only easier.

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 didn't have the chance of working on something in the order of PayPal or eBay, but I still disagree. There is a point in which the answer "throw more hardware" at it breaks, that is usually when you hit the physical constraints of the data center. Nevertheless, I think we are confusing performance and scalability here. Performance is how fast I can do something, scalability is how many concurrent somethings I can do. For the most part, I would worry about scalability more than performance.

Cheap web machines and caching as a scalability measure is one of the easiest routes to scalable applications, and as Evan has pointed out, even minor business logic handling in the database can completely break this model and leaves you with scaling out from the database, which is not a good thing.

So, let me try that comment again:

I can scale up faster and bigger and have more ability to change the application using this approach, rather than spending the time shaving milliseconds now and not being able to respond to change in three months time because of the optimizations that I did now.

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?

I do not assume that all good engineers know & understand NHibernate. I do assume that it is possible to pick up NHibernate in a week or so. Knowledge about NHibernate is simple a pre-requisite for the application, much like knowledge of SQL is. NHibernate is not a "one off" approach because it is not something that is built for this particular project, it is a general framework with a wealth of knowledge, support, community, etc. 

Oh, and did I said that you really want to read Evan's post

Tweet Share Share 5 comments
Tags: