+972 52-548-6969
Application analysis: Northwind.NET
For an article I am writing, I wanted to compare a RavenDB model to a relational model, and I stumbled upon the following Northwind.NET project.
I plugged in the Entity Framework Profiler and set out to watch what was going on. To be truthful, I expected it to be bad, but I honestly did not expect what I got. Here is a question, how many queries does it take to render the following screen?
The answer, believe it or no, is 17:
You might have noticed that most of the queries look quite similar, and indeed, they are. We are talking about 16(!) identical queries:
SELECT [Extent1].[ID] AS [ID], [Extent1].[Name] AS [Name], [Extent1].[Description] AS [Description], [Extent1].[Picture] AS [Picture], [Extent1].[RowTimeStamp] AS [RowTimeStamp] FROM [dbo].[Category] AS [Extent1]
Looking at the stack trace for one of those queries led me to:
And to this piece of code:
You might note that dynamic is used there, for what reason, I cannot even guess. Just to check, I added a ToArray() to the result of GetEntitySet, and the number of queries dropped from 17 to 2, which is more reasonable. The problem was that we passed an IQueryable to the data binding engine, which ended up evaluating the query multiple times.
And EF Prof actually warns about that, too:
At any rate, I am afraid that this project suffer from similar issues all around, it is actually too bad to serve as the bad example that I intended it to be.
Comments
From the project description: "The Northwind.NET site was created to develop and keep a set of sample applications demonstrating various modern technologies and development practices used within .NET Framework and Visual Studio 2008."
I know it hasn't been updated for a while... but come on. It should not be that kind of quality
Databinding to entities is very rarely a good idea. This is really just a demo technique.
I have seen far far far worse in production systems with similar screens. The worst one was 500 Queries for a screen like that. The system was doing eager loading of a whole object models and then filtering in the client.
I know a lot of applications that are much worse than that. It was hard for me to realize one thing: it doesn't matter. They're selling those pieces of crap without any trouble and the end-users never ask why it takes a whole second longer to render a screen as long as they can do what they want.
It's very unfortunate but the reality is, that my beautifully hand-crafted NH-queries don't bring me anything but personal satisfaction.
Sadly Daniel Lang is spot-on. I know it's demo code but it's true in every job I've had - neither the business, management nor the end users gave a care about the quality of the code and would gladly accept hastily-written garbage against DataSets with all the logic in code-behind files over taking the time to have proper abstractions using NHIbernate.
The sad reality is that quality just doesn't matter.
quality will start to matter even to your management when all you see from the competition is the dust settling of them speeding ahead with new features while you are drowning in regressions.
I'm just plain tired of stupid people who misinterprets the word "developer" and mistakenly think of themselves as such.
Not everybody are able to think in the big picture and therefore the misinterpretators should find another way to earn for a living.
Daniel Lang and Wayne M hit spot on. This doesn't just apply to NH-queries. It's code quality overall. Managers and higher ups don't give a crap as long as it works and is delivered on time. I'm currently 'maintaining' several small apps. When I get a chance I clean the code and pray nothing breaks. When I add new functionality, I create new classes instead of using the god class on each project. My boss doesn't care as long as everything works.
I did get the chance to write a very small library as I pleased. I used TDD and clean code, and etc. Did I get pad in the back? Nope. Let's just say the library hasn't been used yet. I created it back in September :)
Only 17? Psh.
I've seen a "My First Nhibernate Code" project in production doing 3000 per screen.
My first day after being assigned to the project I loaded up NHProf and I found the performance problems in seconds.
I demand that you return my EFProf license back to me!
Was doing a tech interview with Mr. Tech and Mr. Manager the other day and Mr. Tech ask what do I think about TDD? I said, oh I'm all about it!!
However, my experience has always been management isn't interested in writing 2 programs (test and actual program to be deployed), funding 2 programs, allocating time to write 2 programs, and finally maintaining 2 programs. Then I turned right around and asked him what he thought about TDD and what was his experience.
He said his experience was identical to mine, so we moved along to the next question. I'm still not sure why he bothered to ask the question. He should know management is a bunch of idiots by now.
It's all a pipe dream folks. Just like a wreck on the highway, move along now, because your boss and the customers could give a crap about your beautiful code.
The problem quite often is the absense of Proof of Concepts, before starting to writing programs. The Idea to pass IQueryable to a binding could sound smart, but then you have to create a POC, test it, verify if it works good, and finally adopt throughout your project.
The other problem is lack of basis. If you find horrible having 17 queries for that screen, I've seen people that wrote this code to get the count of a table out of the db with EF.
return context.TableName.ToList().Count().
Best one I came across was a 30 x 40 report screen that used a SQL query for each cell - re-write reduced it to 6 queries ;-)
Comment preview