Dot Net What Not Posts

I came across an innocent-looking Linq problem the other day that really had me baffled for some time.

It’s easiest explained using the ubiquitous Northwind database (although just about any other relational database would probably do). Suppose you want a list of customers with their orders. Pretty easy eh?

Erm no, it wasn’t!

Although it’s not actually a .NET issue, I decided to blog about it anyway!

I’ve been looking at design patterns quite a lot recently. I have always been a “bung it all in the code-behind” kind of programmer, which is an easy way to program, but messy. You end up with spaghetti code that’s hard to maintain and impossible to test automatically (not that I ever tried mind you!).

I decided to learn some new skills, and discipline myself to programming the Big Boys’ Way. I dutifully went to Amazon and spent far too much on books, and sat down to read them all. Most were fairly tough going and dull. I was beginning to think it wasn’t worth the effort, until I came across Head First Design Patterns, which was a breath of fresh air. Apart from the slightly wacky style, the explanations were very good.

My only gripe with the book is that it’s very Java-oriented. Given that design patterns are language-agnostic, this is totally unnecessary. Most of the time it didn’t spoil the book, but in a couple of places it really annoyed me. However, it’s still the best design patterns book I’ve read by a long way.

I hope to blog more about this subject. Watch this space (unless you’ve got anything better to do of course!)

Linq is great for grabbing entity objects. The code is simple, and you end up with known objects that you can use.

But, when you want to deal with anything slightly off the beaten track, it gets a bit harder. For example, if you have a Linq query that returns an anonymous type, you can easily manipulate it in the same code block.

Here I detail an early exploration into the world of anonymous types