Pixata Custom Controls
For Lightswitch

Recent Posts

Popular tags (# posts in brackets)

Anonymous types (3) ASP.NET (5) C# (3) C# tricks and tips (2) Computers (6) Design patterns (3) DomainDataSource (3) Dynamic data (4) Entity framework (3) Entity model framework (5) F# (3) LightSwitch (12) Linq (6) Microsoft (2) MVP (2) MVVM (2) Project Euler (2) RIA services (5) Silverlight (2) SQL Server (4) Unit testing (4) Visual Studio (7) WCF (3) WPF (3)

Gratuitous link to StackExchange




The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

Actually, as I'm self-employed, I guess that means that any views I expressed here aren't my own. That's confusing!


Theme modified from one by Tom Watts
C#/F# code styling by Manoli (for posts pre-2016) and Google code prettify (for post from Jan 2016 and beyond)

My rambling thoughts on exploring the .NET framework and related technologies

# Sunday, 20 February 2011

Just came across this rather useful post, that documents an obscure problem with what happens if you remove an element from a collection whilst enumerating it. Subtle and insidious, the problem has a simple answer.

Edit (21st July '11): Hmm, seems that post didn't last too long, as it's gone now. I wish I could remember exactly what the problem was! Serves me right for being lazy. (pause...) Ah, found it. Here is a new link that might work.

Sunday, 20 February 2011 16:21:40 (GMT Standard Time, UTC+00:00)

I came across an innocent-looking Linq problem the other day that really had me (and Yossi) 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? You do something like...

from c in context.Customers.Include("Orders") select c;

As you have included the Orders navigation property, this will include every order for the customer.

Now, what happens if you only want to include orders from this year? Sounds like a pretty simple request eh? Well, it isn't! If you were to do this in SQL, you could simply do something like...

select c.CustomerID, c.CompanyName, o.OrderDate from Customers as c
inner join Orders as o on o.CustomerID=c.CustomerID
where o.OrderDate > '1 Apr 1998'
order by CompanyName, OrderDate

Admittedly, this would return a flat dataset, with one row for each order, but you could fix this with some data shaping without too much problem.

Now the obvious thought would be to do something like this in Linq...

from c in context.Customers.Include("Orders") where c.Orders.OrderDate > new DateTime(2011, 1, 1) select c;

The problem is that this won't compile as the Orders collection doesn't have an OrderDate property. Orders is a collection of Order entities.

Well, this one had us going for ages. I posted a question up in two separate forums (fora?), and didn't get very far. Finally, a very helpful person posted an answer that worked.

What you have to do is create a query that creates an anonymous type that includes the Customer entity, and the Orders that you want. Then you create a second query that selects just the Customer entities from the first query...

using (NorthwindEntities context = new NorthwindEntities()) {
  context.ContextOptions.LazyLoadingEnabled = false;
  var customers = from c in context.Customers.Include("Orders")
                  where c.CompanyName.StartsWith("A")
                  select new { Customer = c, Orders = c.Orders.Where(o => o.OrderDate > new DateTime(1998, 1, 1)) };
  IEnumerable<Customer> customers2 = customers.AsEnumerable().Select(c => c.Customer);

What happens behind the scenes is that the Entity Framework uses relationship fixup to sort out which Order entities should be included in the query. I'm not 100% clear hat's going on here, but it works.

Two words of warning here. First, this won't work in the rather excellent LinqPad, as it doesn't support fixup. Second, you need to disable lazy loading.

If you want to read more about relationship fixup, see page 345 in Programming Entity Framework by Julia Lerman. I couldn't find a decent explanation of it on-line.

Sunday, 23 January 2011 15:15:41 (GMT Standard Time, UTC+00:00)
# Sunday, 19 December 2010

I found a neat trick the other day, and thought I would add it here in case it's of use to anyone.

I had a class, call it Ferret for the sake of argument, and I was handling a List<Ferret> collection. Although the order of the List<> was generally unimportant, I came across one instance where it would have been useful to sort them.

Now the obvious way to do this is to have the class implement IEnumerable, and add the appropriate method. However, I found that you can sort a List<> on the fly like this...

ferrets.Sort(delegate(Ferret f1, Ferret f2) { return f1.name.CompareTo(f2.name); });

This saves mucking around defining interface methods when you don't need them. Obviously, if you are going to sort the List<> regularly, then it's probably worth implementing IEnumerable, but for one-off usage like mine, this is a neat trick.

Edit (21st July '11): I found out later that you can do this even more simply with Linq...

ferrets.Sort((f1, f2) => f1.name.CompareTo(f2.name));
Sunday, 19 December 2010 21:05:28 (GMT Standard Time, UTC+00:00)
# Sunday, 19 December 2010

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!)

Sunday, 19 December 2010 20:56:35 (GMT Standard Time, UTC+00:00)

Well, after realising (or even RIAlising if you like puns) that RIA services weren't cut out for non-Silverlight clients, I went searching for The Next Big Thing. Can't remember if I mentioned it, so I'll bore you by repeating it, but all of this investigation is for a big project I'm in that will need some sort of central data access point that can be used by all sorts of clients, most likely being WinForms, WPF (one of my colleagues is really excited about WPF), ASP.NET and Silverlight. Ideally, we want all of these to be able to use the same point of access for data, with the business logic behind that point of access.

RIA looked like the answer, but doesn't seem to play ball with anything other than Silverlight. So, I went looking at its big brother WCF. The idea was to build an end-to-end solution that had a WCF service on top of an entity framework model, and various clients consuming the service.

This posts describes my initial excitement, great disappointment and final happiness (so far) with consuming a WCF service in WinForms, ASP.NET and Silverlight.

Tuesday, 26 October 2010 15:14:16 (GMT Daylight Time, UTC+01:00)

Avid readers (if there are any!) may remember my recent post in which I extolled the virtues of the DomainDataSource control, and how it enabled us to use RIA services in ASP.NET sites. Well, having bashed my head against the wall for a week or so trying to get RIA services working with ASP.NET, I have decided that the support for this is actually quite limited, and not enough to make it a viable option.

This post gives more details of my exploration, discoveries and eventual disappointment at the conclusion.

Tuesday, 12 October 2010 15:48:05 (GMT Daylight Time, UTC+01:00)

Well, having posted about my excitement over discovering ASP.NET Dynamic Data (ADD), I spent the last couple of weeks digging deep into it, and have eventually come to the conclusion that it was a great idea, but ultimately of little use. I mentioned a few misgivings in that previous post, and I've added a few more to the list. All in all, I don't see me using this technology much.

Having spent so much time on it, I had about ten blog posts in my head, explaining what I'd learnt, but I guess they stay in the recesses of my mind until they fade away into synaptic relapse.

This post explains why I'm moving on.

Sunday, 19 September 2010 15:40:07 (GMT Daylight Time, UTC+01:00)

I recently discovered Microsoft ASP.NET Dynamic Data(or ADD for short). I know, some would say I'm slow off the mark, but I never have time to keep up with all the new technologies MS are putting out. Anyway, this one looked interesting, so I decided to devote some time to investigating it. I must say I was (to quote the vernacular), somewhat gob-smacked by it! One of the reasons it took me so long to get around to looking at this was that MS seem to have forgotten to promote it. Even the Dynamic Data section of the www.asp.net web site (when you can find it) doesn't really tell you what it's about. One look at that would be enough to make me yawn and go somewhere else.

If you've written any reasonable sized database-driven web sites, then you'll know that the painful bit is writing a whole pile of administration pages so that the site owner can maintain the site. You end up doing almost exactly the same thing over and over again. When you've done it for the 97th time, you really wonder why there isn't a better way.

Well, now there is - maybe. Enter ASP.NET Dynamic Data. Now you can have a fully-featured CRUD web site in seconds (no, not an exaggeration).

In this post, I explain what it's about, and why you should have a look.

Monday, 06 September 2010 16:27:50 (GMT Daylight Time, UTC+01:00)

As I mentioned in my post about the DomainDataSource control (DDS), the same RIA services toolkit that provides the DDS also supplies a validator control called the DomainValidator. As this provides such a useful piece of functionality so easily, I thought it was worth a quick post about it.

Using the DomainValidator control, you can add validation to your ASP.NET pages really quickly and easily, and preserve the n-tier structure of your application - something you coudln't do with the regulat ASP.NET validators.

Wednesday, 18 August 2010 15:53:40 (GMT Daylight Time, UTC+01:00)
# Tuesday, 17 August 2010

Unlike its predecessors, the DomainDataSource control is a brilliant feature that you can use with RIA services to have code-free access to your data from the ASP.NET page - without sacrificing the structure of your application.

Previous data controls required data access code in the control, so you ended up with SQL in the presentation layer. Not a good idea. The DomainDataSource control doesn't do this, and is a vauable addition to your ASP.NET/RIA services toolbox.

This post explains what the control is, and shows how to use it.

Tuesday, 17 August 2010 14:30:05 (GMT Daylight Time, UTC+01:00)