Post by Erland SommarskogPost by Jeroen MostertI think all of these things are for wimps, and use SqlCommand and
SqlDataReader directly on stored procedures.
Really? I also stick to SqlCommand, but it's not beacuse I am a brave man.
Rather, things like LINQ and EF makes me scared, as I have no idea what is
generated behind the scenes. This is the no least important when there
are complaints about poor performance.
Both LINQ to SQL and EF have features for turning on logging of the commands
generated, and of course you've got profilers. Although you can still make
the argument that you don't *really* know what's generated unless you get to
100% code coverage, and MS could (and does) change the algorithms with new
releases, peeking behind the curtain is really not that hard. Both LINQ to
SQL and EF are strongly typed, meaning the code isn't dynamic: it's a fixed
set of SQL, you just can't immediately see it.
My main issue is that, at best I'll see that the code is efficient (great)
and at worst I'll see I need to stick in a stored procedure to compensate
for code that's not (and I hope you can use a stored procedure, otherwise,
have fun creating and maintaining query plan guides). So why not just cut
out the middleman and write SQL directly? I know how to do that, having a
computer program do it for me doesn't save me a lot of time.
That said, I don't write many things with a GUI. It's all service-oriented
backend stuff, many different services running on the same database. Dynamic
code generation is actively harmful, while stored procedures serve as a
logical interface and offer an extra layer of customization if you need to
patch something and can't modify the binaries.
If all I had to do all day is write CRUD apps that use their own databases
exclusively, I'd definitely use an ORM. Probably EF.
Thank you both. A question to both: what do you write production code
in?
You'll have to be more specific. In what language? What IDE? What state of
mind? Which clothes?
For me it's C#, VS 2012, bemused and smart casual, in that order. But I'm
not married to any of it.
And I understand the Microsoft team is working hard to increase performance
in EF and .NET (the latest Visual Studio 2012 in .NET is much faster than
previous versions say some). Then again, if you're a die hard fan of
performance even an extra 10 millisecond lag is too great--for example the
London Stock Exchange wrote a good version of a stock trading platform in
.NET, then had to scrape it when they found out "program traders" needed a
few more milliseconds faster performance otherwise they would move to the
NYSE.
Stock trading is an extreme example. For the most part, that doesn't even
involve databases all that much, as disk I/O is just *too slow*. You're
talking Complex Event Processing on ridiculous hardware with custom code.
Even garbage collection is suspect in environments like those. Time is quite
literally money.
An expensive mistake but for most places I would think .NET is more than
good enough, especially for maintenance where a good portion of
programming is done.
If you're talking pure database code, you're I/O bound anyway. Saving a few
microseconds in the app while your database spends milliseconds on
transactions isn't going to make the difference. If your app is interactive,
you're human-bound and your only perf concern should be making the UI
snappy. For the rest, as always, a good algorithm on a slow runtime will
beat a bad algorithm on a fast runtime every day. The remainder where it
finally starts to matter what language/runtime your code is in usually still
has its performance concerns dwarfed by its maintenance costs.
In short, language bigots can suck it.
--
J.