The normalized data model of the database is often not suitable for reading and displaying data. A separate read model used to represent all the data needed to display a page improves performance.
Defining the read model is only half the work though, to make it really usable the read model should accept queries in the same way as the write model (the DB Entities) does. In .NET/C# that means that the read model should implement IQueryable<T> to enable it to be queried with LINQ. By building the read model on top of the write model it becomes a breeze.
from c in ctx.Cars.SelectCarReadModel()where c.Car.CarId== id
select c
from c in ctx.Cars.SelectCarReadModel()
where c.Car.CarId == id
select c
A call to an extension method is all that’s needed – the query above produces a CarReadModel result, containing the additional data needed for displaying that’s not directly part of the Car entity.
Last week I showed some ways to utilize extension methods. In this post I’ll go on with a more advanced example and also discuss some of the limitations.
Method-Only Multiple Inheritance
A combination of interfaces and extension methods can be used to partly work around the single inheritance limitation of C#. Assume that I have a class hierarchy of animals. Some of the animals are possible to ride, but they are spread across the hierarchy and cannot share a common base class. In C# we can use an interface to get a type safe way to indicate that an animal is possible to ride.
Extension methods were first introduced with LINQ in C#3.0. They are just a syntactic construct, but as we’ll see in this post they can make a huge difference. What’s easier to read of these two?
string[] wishList1 =
Enumerable.ToArray(
Enumerable.Select(Enumerable.Where(Animals, a => a.StartsWith("A")),
a =>string.Format("I want a {0}.", a)));string[] wishList2 = Animals.Where(a => a.StartsWith("A")).Select(a =>string.Format("I want a {0}.", a)).ToArray();
string[] wishList1 =
Enumerable.ToArray(
Enumerable.Select(Enumerable.Where(Animals, a => a.StartsWith("A")),
a => string.Format("I want a {0}.", a)));
string[] wishList2 = Animals.Where(a => a.StartsWith("A"))
.Select(a => string.Format("I want a {0}.", a)).ToArray();
To me, the second alternative has several advantages:
Get rid of the name of the helper class declaring the method. Writing out the Enumerable class name doesn’t add any relevant information. On the contrary, it forces the reader to actively think of it to find out that it is irrelevant.
Left-to-right reading order instead of inside-out when following the evaluation order.
The method name and the parameters are written together. In the first example Select and the relevant code is splitted by the call to Enumerable.Where.
Extension methods creates a syntactic possibility to do two important things that are not allowed by the language.
In the Type Safe SelectList Factory post I showed one way to improve the SelectList constructor. Recently I wrote another one, when I needed a SelectList that has the selected item’s index as the value. I used this together with jQuery to get details about the selected item from a separately supplied json array.
Often we cannot be sure if a parameter passed in to a function has a value. To write error safe code all those parameters have to be checked for null and handled. We have the ?? coalesce operator to help, but still it can be quite a lot of code. Through the use of extension methods a lot of cases can be handled. As extension methods are in reality static methods of another class, they work even if the reference is null. This can be utilized to write utility methods for various cases. In this post I’ll show two cases, one is an extension that returns a default value for an XML attribute value if the attribute or even the element is missing. The other one handles the common case when a null sequence reference passed should be handled as an empty sequence.
