Simon Ince's Blog : C#

String.Unformat: I've created a monster

simonince — Thu, 09 Jul 2009 20:42:00 GMT

I don’t know if you’re the same, but when coding away I often find myself wishing for a String.Unformat function – call it the evil twin of String.Format. With String.Format I can build up strings like this;

var result = String.Format(

"http://{0}:{1}/{2}",

"localhost",

"12345",

"TestPage.aspx");

... which will return "http://localhost:12345/TestPage.aspx".

But what if I want to do the opposite; split out the contents of this URL, in one easy statement, much like String.Format? What if I could do this...?

string input = @"http://localhost:12345/TestPage.aspx";

object[] results = input.Unformat(@"http://{0}:{1}/{2}");

CollectionAssert.AreEquivalent(

new object[] { "localhost", "12345", "TestPage.aspx" },

results);

Of course something similar is already possible with Regular Expressions, but I find them much more unwieldy, they result in longer code, they’re overkill for what I’m trying to achieve, and they’re difficult to remember the syntax (oh, and even harder to get it right when coding late at night!). Take this equivalent example and judge for yourself;

string input = @"http://localhost:12345/TestPage.aspx";

string matchingformat = @"^http://(?<C1>.+):(?<C2>.+)/(?<C3>.+)$";

Regex expression = new Regex(matchingformat);

Match match = expression.Match(input);

Assert.AreEqual<object>("localhost", match.Groups["C1"].Value);

Assert.AreEqual<object>("12345", match.Groups["C2"].Value);

Assert.AreEqual<object>("TestPage.aspx", match.Groups["C3"].Value);

To get around this I have created my own String.Unformat function... all it does is take a simple format string and convert it into a regular expression by applying a number of transforms to it. And how do we do these transforms? With regular expressions, of course J

Now before we dive in here, I must make a point. This is not a replacement for regular expressions. It will be difficult to get the precision you need for anything complex – I’m only after a quick and simple solution to the basic case problem. Knowing this, read on...

How it does it

My sample code (and a bunch of demonstrations in the form of unit tests) is attached. Basically there are five phases to the code;

1. It escapes any special Regular Expression characters (e.g. ^, [, ], $ and so on) with a backslash so that they don’t accidentally affect the matching... they are assumed to be literal in the input string.

2. It replaces the {0} match syntax with regular expression (?<C1>.+) syntax.

3. It adds begin (^) and end ($) markers to the match string.

4. It performs the match.

5. It loops through the results, extracting matches and adding them to an object array to return.

Have a look in the attached and see what you think.

But...

The regular expressions I’m using are compiled where possible... but of course I’m applying multiple transforms (i.e. regular expressions) to a string just to do a simple match.

What does this mean? It means this will always be slower than if you just wrote a regular expression yourself (check out here and here if you want to)... so if performance really is that key to your code, or you’re doing this in a long loop, you might want to avoid it. If on the other hand you can see a great use for this when performance isn’t key – give it a go and let me know what you think!

I have also not had time to write a full suite of real unit tests, so if you find a bug shout up.

Conclusion

What do you think? Have I created a monster, or cooked up a treat?

After writing this I came across an interesting conversation here... it seems I have not been alone in my desires for String.Unformat.

foreach keyword or ForEach extension method?

simonince — Mon, 27 Apr 2009 18:21:00 GMT

Is this a question of taste, or something more serious? [Warning: this post won’t change your life J]

I found myself writing the following extension method yet again the other day;

public static void ForEach<T>(

this IEnumerable<T> source,

Action<T> action)

{

foreach (T item in source)

{

action(item);

}

This means I can write simple (contrived) code like the following;

entities.ForEach<ObjectDefinition>(o => o.DeleteDbRecord());

This will enumerate all my ObjectDefinition objects and call DeleteDbRecord on each. But why didn’t I just write it like this?

foreach (ObjectDefinition o in entities)

{

o.DeleteDbRecord();

}

I’ve raised this because some code I’ve seen (and written!) has reached a saturation point, where lambdas, extension methods, and other concepts have taken over - meaning the code looks more like it was written in LISP than C#.

But does that matter?

A quick search shows there are all sorts of discussions about this online, which is interesting. It is actually quite an old discussion now!

All About Lamdas

simonince — Thu, 29 Jan 2009 12:58:00 GMT

I’ve been reading Mike Taulty’s blog for ages now, and I love his balance of technologies, the length of his posts, and his style of writing. So if you’re not a subscriber, go check it out.

But I just had to draw attention to his recent post – “Anonymous Methods, Lambdas, Confusion”. It’s a well written walkthrough of how Delegates have evolved into Lambdas and more – so if you’ve seen code that looks a bit like this;

int result = Calculate(

list,

(a, b) => (a * b) * 2);

And you’ve thought “what the...?!” - I’d recommend giving it a read.

Lamba Expressions to the Rescue!

simonince — Mon, 08 Sep 2008 19:30:00 GMT

Maybe I’m biased because he’s on the same team as me (ahem, sorry for the plug J), but I really liked Stuart Leeks’ post on improving the “Include” method on ObjectQuery<T>.

It’s another example, like the MVC Framework he mentions, of how lamba expressions can be used in the real world to add type safety and easier programming constructs.

Make sure you check out his post here.

Strongly Typed Primitives

simonince — Fri, 15 Aug 2008 16:32:00 GMT

No, I’m not talking about NEANDERTHALS (there’s a joke in there somewhere), but rather a technique that a colleague of mine, Josh Twist, has recently blogged about – “Avoiding Primitive Obsession to tip developers into the pit of success”. I’d always seen a pit as symbolic of failure, so I’m pretty pleased there’s such a thing as a pit of success – improves my odds massively J

I’ve drawn attention to this because it is an approach I discovered a few years back, and I love it. I just use a slightly different implementation to Josh;

public class Command

{

#region Structure

private string _name;

private Command(string name)

{

_name = name;

}

public string Name

{

get

{

return _name;

}

#endregion

#region Instances

public static Command Profile = new Command("Profile");

public static Command WebExecute = new Command("WebExecute");

#endregion

}

You can see that I use a single class to encapsulate both the behaviour of the Command class and the static instances of a Command.

I can’t really think of a convincing reason why one of these would be better over the other to be honest – I guess Josh’s approach means you could have different collections of commands (WebCommands, WindowsCommands, SomeOtherCommands), but I’ve never needed to do that. Any other reasons you can think of?

Still – read Josh’s post and see what you think. This kind of pattern is so simple yet so effective at eliminating mistypes, increasing code readability, and improving refactoring (just try deleting a command type and watch that compiler pick up everywhere you need to make a change!).

Good stuff.

C# "var" Keyword: We Need Your Vote!

simonince — Fri, 18 Jul 2008 17:11:00 GMT

Josh Twist is running a vote on the use of the “var” keyword. Get voting!

Oh, and make sure you vote “var is for anonymous types only” or he’ll never let me live it down. Ever. I’ll be watching J

Aspect Oriented Interception

simonince — Tue, 24 Jun 2008 12:38:00 GMT

Have you used Aspect Oriented Programming (AOP) or Policy Injection? They’re pretty much the same thing. If you haven’t, I’d highly recommend doing some reading, as I believe it is a Software Engineering practice that has moved out of the “fashionable” and into the “enterprise”. For separation of concerns it is a fantastic paradigm.

I’ve done a number of demos now, on topics like the Web Client Software Factory and how it integrates with the Enterprise Library, and when I get to the bit that I add an attribute to my code like this;

[Log]

public void SaveCustomerRecord()

{

// ... implementation

}

... and click run, only for the attendees to see all the logging happening as if by magic, there is often an impressed intake of breath. There are of course other ways of applying “aspects”, using configuration for example, but this is a quick and easy example.

I’m going to assume you’re aware of the basic principles of AOP – if you’re not, try having a read of some of these resources;

· Wikipedia’s definition of Aspect-Oriented Programming

· Spring .NET’s AOP Chapter

· Type AOP into a search engine (Live Search, obviously J)

To get a basic understanding, make sure you know about aspects, targets, join points & point-cuts, advice, and introductions. One often overlooked one you should know about is weaving.

Weaving Aspects

Weaving is all about adding the calls to your aspects into the existing code. So imagine we have a method that looks like this (* note: excuse the terrible code, it is only meant to be illustrative!);

[Log]

public void SaveCustomerRecord(int id, Dictionary<string, object> values)

{

Customer customerRecord = new Customer();

customerRecord.ReadFromDatabase(id);

customerRecord.UpdateDetails(values);

customerRecord.Save();

}

... then adding the calls to “Log” might effectively change my code to look like this;

public void SaveCustomerRecord(int id, Dictionary<string, object> values)

{

try

{

Logger.LogMethodEntry();

Customer customerRecord = new Customer();

customerRecord.ReadFromDatabase(id);

customerRecord.UpdateDetails(values);

customerRecord.Save();

}

catch (Exception e)

{

Logger.LogException(e);

throw;

}

finally

{

Logger.LogMethodExit();

}

I’m sure you can see the difference; we now log entry to and exit from the method, and any errors we encounter. So something must alter the code to do this, right?!

Well, yes! That is, either the code is changed, or the call is intercepted and rerouted.

It turns out there are a few ways of doing this, and we’ll cover what these are below, seeing the differences as we go.

Interception Mechanisms

1: Interface Proxy

The “interface proxy” method looks like this;

In this scenario, the “target” class must implement an explicit interface. The runtime can then create its own runtime implementation of this interface that simply intercepts the calls, processes the relevant aspects, and then (if applicable) calls onto the real target object. An example of this using Spring .NET is below;

public interface ITarget

{

void DoSomething();

}

public class Target : ITarget

{

public void DoSomething()

{

Console.WriteLine("I'm doing something...");

}

public class Program

{

public void Run()

{

ProxyFactory factory = new ProxyFactory(new Target());

factory.AddAdvice(new LoggingAspect());

ITarget target = (ITarget)factory.GetProxy();

// do it!

target.DoSomething();

}

Here we can see that our Target class implements ITarget, and that when we retrieve a proxy to it, we actually get a dynamically created implementation of ITarget, that calls LoggingAspect and then passes the call onto our real Target class. Note that the configuration of the factory, when we add advice, could be done in configuration.

So this is a really nice way of doing things, but some people don’t like having to have an interface for every class they want to intercept. And I don’t blame them – if you use an aspect for logging, you might want it on every single class! That’s a lot of interfaces...

This is the mechanism that most of the .NET AOP frameworks use, to some extent; Spring .NET, the Enterprise Library Policy Injection block (although the docs tell us the PIAB is not an AOP framework, it is close enough for this topic), Castle Windsor’s Dynamic Proxies...

2: Remoting Proxy

Our next option is to use some cleverness built into the Remoting infrastructure in .NET.

I’m not going to go into the detail (if you really want to know, there’s some info here), but basically this allows us to intercept calls to any method on our Target object. Of course, this doesn’t come free. In fact, it down right hurts – we have to inherit from MarshalByRefObject, and there is likely to be a performance hit. Let’s see an example using the PIAB;

public class Target : MarshalByRefObject

{

[LogCallHandler]

public void DoSomething()

{

Console.WriteLine("I'm doing something...");

}

public class Program

{

public void Run()

{

Target target = PolicyInjection.Create<Target>();

// do it!

target.DoSomething();

}

Notice a few things in this code; firstly, we must inherit from the dreaded MarshalByRefObject (which of course prevents us from inheriting from anything else our code might find more useful). Secondly, note that I’ve chosen to use an attribute (“LogCallHandler”) on a method to apply an aspect to the target. Some people hate this (mainly because of the coupling between target and aspect) – you can do it in config if you wish. Lastly, note that we create an object using an overload of PolicyInjection.Create that supports using a class with no interface (or the alternative Wrap method).

Again, many frameworks support this approach.

3: Inheritance Proxy

The third option is an inheritance proxy, characterised by the following diagram;

Why, when the two above methods can do everything we need? Gotcha; they can’t do everything we need. There’s actually a big hole in what we’ve already covered. Consider the following code, adapted from the example in option (2) – and look carefully;

public class Target : MarshalByRefObject

{

public void DoSomethingFirst()

{

// pass on the call

DoSomething();

}

[LogCallHandler]

public void DoSomething()

{

Console.WriteLine("I'm doing something...");

}

public class Program

{

public void Run()

{

Target target = PolicyInjection.Create<Target>();

// do it!

target.DoSomethingFirst();

}

All I’ve done is to introduce a new method; now my Program class calls “DoSomethingFirst”, which in turn calls “DoSomething”. This second method is the one that has the logging aspect applied to it.

But of course, our aspect is invoked by a Proxy, and when DoSomethingFirst calls to DoSomething, it does it using the “this” keyword (implicitly). Therefore this call is not going via the proxy, and therefore no aspects get invoked. Owch! So my AOP mechanism only works when calling to a different object!

Now this isn’t a show-stopper, as long as you understand this behaviour, but it is a bit of a pain, which is why the inheritance proxy approach can be useful.

OK, now we need to switch frameworks as the PIAB doesn’t support inheritance proxies... let’s use Castle Windsor’s DynamicProxy2, tweak our example to mark its methods as virtual, and get rid of the MarshalByRefObject base class;

public class Target

{

public virtual void DoSomethingFirst()

{

// pass on the call

DoSomething();

}

public virtual void DoSomething()

{

Console.WriteLine("I'm doing something...");

}

public class Program

{

static void Main(string[] args)

{

ProxyGenerator factory = new ProxyGenerator(

new DefaultProxyBuilder());

Target target = factory.CreateClassProxy<Target>(

new LoggingInterceptor());

// do it!

target.DoSomethingFirst();

}

This means our reference to what we think is a Target class is now actually a dynamically created subclass of Target... perhaps something like this (note: I’m massively simplifying intentionally);

public class GeneratedTargetSubClass : Target

{

public override void DoSomethingFirst()

{

AOP.CallBeforeAspects();

base.DoSomethingFirst();

AOP.CallAfterAspects();

}

public override void DoSomething()

{

AOP.CallBeforeAspects();

base.DoSomething();

AOP.CallAfterAspects();

}

Now, immediately our Target class calls from one of its members (say DoSomethingFirst) into another (such as DoSomething), the call will go through our generated subclass, and hence our aspects will be executed successfully.

4: Modified IL

The last, and probably most impressive approach, is to literally compile the aspects into the IL. IL is “intermediate language”, basically what all .NET code (VB.NET, C#, J#... anything) compiles to, and is pretty much equivalent to Java’s bytecode. Speaking of Java, in Java-land AspectJ can compile aspects into the bytecode using a post-processing step.

In .NET, there are a couple of options for doing this – namely PostSharp and AspectDNG (based on Cecil). For PostSharp, the third and (hopefully) final Release Candidate was recently announced, so I thought it was high time I had a look.

So in our fourth case the diagram looks like this;

This clever approach lets you write aspects that are compiled into the IL in a post-processing step. For PostSharp, the installer also hooks into MSBuild so that it all happens automatically if you reference the PostSharp assemblies. We can specify aspects using attributes again, so have a look at the following code;

public class Target

{

[LoggingAspect]

public void DoSomething()

{

Console.WriteLine("I'm doing something...");

}

public class Program

{

public void Run()

{

Target target = new Target();

// do it!

target.DoSomething();

}

The first thing you should notice is that there is no need to generate a proxy, wrap a proxy, intercept calls using a remoting infrastructure, or anything else. Just create a Target and call its method. That’s because the [LoggingAspect] attribute is weaved into the main code for DoSomething at compile time.

Our LoggingAspect implementation could look something like this;

[Serializable]

public class LoggingAspect : OnMethodBoundaryAspect

{

public override void OnEntry(MethodExecutionEventArgs eventArgs) ...

public override void OnExit(MethodExecutionEventArgs eventArgs) ...

public override void OnSuccess(MethodExecutionEventArgs eventArgs) ...

public override void OnException(MethodExecutionEventArgs eventArgs) ...

}

If we now look at a sample of the code that exists in our compiled .NET assembly, you might be surprised how little it looks like the code we wrote!

PostSharp has “weaved” (how appropriate does that term seem now you see the code?!) calls to our aspects into the DoSomething method. We could also have applied our attribute at the assembly level – semantically equivalent to “intercept all calls to methods that start with a Y in this assembly”, for example.

Perhaps the biggest issue here that doesn’t apply to the other approaches is that you cannot dynamically apply or remove aspects using configuration, after compile time. But then, you can build config into your aspects – so a logging aspect may have an on/off switch for example. This is not quite the same, so think about it carefully if this matters to you.

What I really like is that I don’t need some kind of factory to create or wrap my objects, and that my code is fixed into the assembly – which surely should perform well? I put a question mark here because PostSharp does still use reflection, so I’d be keen to see some comparisons... but still, it isn’t proxying every call. And of course the aspects will be applied across all calls – not just those from a different object!

Conclusion

I hope that’s been a useful little look at how some of these AOP frameworks (*) work in the background. The key takeaway is that there are differences in behaviour that can affect you when using these frameworks. There are also differing levels of abstraction and decoupling – so choose carefully!

I personally love the idea of compiling aspects into the IL. In fact, I’d love to see making this kind of compiler-level extension easier in .NET some day. I can’t quite get my head around how it would work, but I wonder if lambda expressions and LINQ might work together nicely to help here in some way... more thought required I think.

One important point to note is that I have deliberately not compared the frameworks against AOP principles, the quality of their point-cut language, and so on... if you’re interested in those, do some reading and let me know what you think! A good starting point is the AOP Alliance.

Anyway, happy point-cutting!

* yes I know some of them don’t claim to be AOP frameworks, but they’re frameworks that help with AOP, or are approaching AOP, that’s good enough for me J

Useful Links

Check these out for some more information... and there are many more too!

· The PostSharp home page

· The AspectDNG home page (and Cecil)

· Tom Hollander’s original PIAB announcement

· The Enterprise Library (you want versions 3+ for the PIAB)

· The Castle Project (for Castle Windsor etc)

· The Spring Framework for .NET

Also, after writing 99% of this article, I found a great little post by Ayende comparing approaches to AOP in .NET – worth a quick read.

Self-Referencing Generics: Follow-up

simonince — Mon, 16 Jun 2008 14:32:00 GMT

After being prompted by a friend (or ex-colleague, or drinking buddy, whatever you want to be called J) I think I owe further explanation about my previous post on generics.

Consider these two classes;

public class FirstClass<T>

{

public FirstClass<T> Parent;

}

public class SecondClass<T>

{

public T Parent;

}

Now, if I subclass each of these classes to shape the two approaches (First is the common way to do things, Second is using a self-referencing generic);

public class FirstSubClass : FirstClass<string> { }

public class SecondSubClass : SecondClass<SecondSubClass> { }

... the way in which we can use these is very different. Taking the First example, what do you think to the following code?

1: FirstSubClass subclass = new FirstSubClass();

2: FirstClass<string> parent = subclass.Parent;

3: FirstSubClass parent2 = subclass.Parent;

I’ve added line numbers for clarity. As you can see, Line 2 is valid, but Line 3 won’t compile. This means my “Parent” property is strongly typed at the base class, and if I need an instance of the sub class I must manually cast it. This is absolutely what you want sometimes, as when defining a typical Object Oriented inheritance hierarchy it makes sense – in fact, this is polymorphism in action.

Now consider the code for our Second example;

1: SecondSubClass subclass = new SecondSubClass();

2: SecondClass<SecondSubClass> parent = subclass.Parent;

3: SecondSubClass parent2 = subclass.Parent;

With this approach, our Parent property is strongly typed as the subclass, which makes all of the statements above compile.

This is particularly useful when you want to have navigable chains of objects (such as my linked list example) or to strongly type as the implementing class, not the base class. What we’re effectively doing is delaying the declaration of a type, and avoiding polymorphism because we know our consumers will always want an instance of the subclass.

Keen-eyed readers may have noticed the two classes are not equivalent, as one obviously holds a string, and the other cannot. To prove it is possible;

public class ThirdClass<T, U>

{

public T Parent;

public U Value;

}

public class ThirdSubClass : ThirdClass<ThirdSubClass, string> { }

Hey presto, a new base and subclass that expose a string value and a Parent.

Example Please!

OK, so a simple example is warranted perhaps.

One of my pet hates is ICloneable – it returns an object, and I wish it was strongly typed. Well, here’s another version of ICloneable;

public interface ICloneable<T>

{

T Clone();

}

Sure, I know this is an interface not a base class, but the concept is the same. Anyway, what this means is that I can implement my new ICloneable<T> in a class;

public class CloneableClass : ICloneable<CloneableClass>

{

public CloneableClass Clone()

{

// really basic implementation!

return this.MemberwiseClone() as CloneableClass;

}

... and hey presto, I have a strongly typed implementation of cloning.

Problems

As with all seemingly nice answers to little problems, there are some gotchas, so exercise caution.

1. I can’t use a base class of ICloneable<object> to refer to my ICloneable<T> implementers – this just doesn’t work with generics.

2. In all of these examples, you are effectively tightly coupling the base class and subclass. The base class dictates exactly how a subclass must use it. For example, what if a class implements ICloneable<string>? This will compile and work, but is semantically different to what I intended, and could confuse the socks off a development team! Lesson: if you’re going to use this, consider doing it internal to your library – be careful about using it in a public API!

3. I wasn’t really condoning the “object.Next.Next.Next.Previous.Age” coding approach I used in my last post; it was merely to show that it was possible, and that the navigation properties and value properties now exist on the same type. Please don’t use lines of code like that or the rest of my team will come to get me when they're doing code reviews... J

Generics: The “Self Referencing Generics” pattern

simonince — Thu, 12 Jun 2008 18:55:00 GMT

OK, so it isn’t really a sensible name for a pattern. In reality, this post is just about a useful technique to use when developing with generics that initially can feel a little counter intuitive. I’ve found many uses for it, so I think it is worth sharing.

Putting the basics in place, remember that .NET 2.0 introduced the concept of generics, whereby I can define a type that has an additional “type parameter”. This means that I can vary aspects of my implementation class in a strongly typed way.

For example, the following defines a type that can be instantiated to store a value of any type;

public class ValueHolder<T>

{

private T _value;

public ValueHolder(T value)

{

_value = value;

}

public T Value

{

get

{

return _value;

}

I would then create instances of ValueHolder<int>, ValueHolder<string>, and so on.

To the unaccustomed eye, this can seem strange, but once you understand the basics it is straightforward. If you need to brush up on Generics I’d recommend the “Introduction to Generics” from the C# Programming Guide.

Self-referencing Generic Types

So let’s introduce the concept of inheriting from a generic type. For example, I could subclass ValueHolder in the following ways;

public class SubValueHolder : ValueHolder<string>

{

// implementation

}

public class SubValueHolderToo<T> : ValueHolder<T>

{

// implementation

}

The first hard-codes the “string” implementation of ValueHolder, and the second allows the user of the class to specify the generic type parameter still. So the first example is now a concrete type definition with no generic type parameter... so could I supply it as the generic type parameter to the ValueHolder base class? Rather than repeat that pseudo-nonsense, let me show you what I mean;

public class SubValueHolderThree : ValueHolder<SubValueHolderThree>

{

// implementation

}

In other words, SubValueHolderThree is both defined and used as a type parameter on the same line. And the answer is “yes, you can”! This means that lines such as the following are valid code;

SubValueHolderThree three = new SubValueHolderThree();

// ... setup code removed...

three.Value.Value.Value.Value.Value = myValue;

... and of course the use of this nested Value property can repeat to your heart’s content. Useful huh?

No? What do you mean?! Well I guess you have a point...

Useful Self-Referencing Generic Types (1)!

Chances are the previous example isn’t quite as useful as you were hoping. However, there are two examples where this technique is very useful. The first example is when a repeating pattern really is what you want;

public class LinkedListBase<T>

{

public T Next { get; set; }

public T Previous { get; set; }

}

public class PersonLinkedList : LinkedListBase<PersonLinkedList>

{

public string Name { get; set; }

public int Age { get; set; }

}

In this scenario, we have just created a PersonLinkedList that will allow code such as the following;

PersonLinkedList personlist = new PersonLinkedList();

// ... setup code removed...

string name = personlist.Next.Previous.Next.Name;

Now with a linked list, it is logical to expect this to work, and indeed it does perfectly, allowing you to put all manner of common logic in the LinkedListBase class. Contrast this to a traditional linked list implementation with generics and you would have to define a “TheValue” property on the linked list base class, like this;

public class Person

{

public string Name { get; set; }

public int Age { get; set; }

}

public class OldLinkedListBase<T>

{

public T TheValue { get; set; }

public OldLinkedListBase<T> Next { get; set; }

public OldLinkedListBase<T> Previous { get; set; }

}

Which means you must write code that looks like this;

OldLinkedListBase<Person> personlistToo = new OldLinkedListBase<Person>();

// ... setup code removed...

personlistToo.Next.Next.TheValue.Age = 10;

The extra requirement to access a property that contains the entity I’m after is pretty ugly, I reckon, and it doesn’t suit the scenario where the “listed” object should semantically contain the Next and Previous links (or Parent and Child on a Person object, for example).

Useful Self-Referencing Generic Types (2)!

The second useful example is when you want to implement the Singleton pattern across a common set of subclasses. Consider the following definition;

public class BaseClass<T>

{

public static readonly T Instance = default(T);

}

public class SubClass : BaseClass<SubClass>

{

public string Name { get; set; }

}

Using a self-reference as the generic type parameter when writing the subclass means two things; firstly we get a static Instance property that is defined as type SubClass (perfect for Singleton!), and secondly we get access to all the instance members on that single instance of SubClass. So, without writing anything else, this code will work;

SubClass.Instance.Name = "Simon";

What is even better, is that I can add as many different subclass types as I like, reusing my Singleton implementation every time. Handy, huh?

Conclusion

Well, I’m sure this has started you thinking now... and of course there must be many different applications for this approach. It isn’t a revolutionary idea, but it does demonstrate one of the less well known benefits of generics. Do let me know if you find a particularly interesting implementation for the idea.

Two little disclaimers:

1. Note that I have not discussed the requirement for managing concurrent access to data when using the Singleton pattern as that is not the point of this post, but suffice to say that the above will work but needs more work before it is real-world ready. If you’re interested in this, I’d recommend reading “Exploring the Singleton Design Pattern” and “Implementing Singleton in C#”.

2. Do you really need a Singleton? Are you sure? Are you just using it to hold global variables when you shouldn’t be, or making it easier to reference other objects, or trying to reduce the number of objects your application instantiates? If the answer is yes to any of these, I’d recommend reconsidering: Singleton is great for controlling truly shared data that needs concurrency management for updates in memory, and in general not so great for other scenarios.

Adding messages to a Validation Summary

simonince — Thu, 28 Feb 2008 23:21:00 GMT

For a while now I’ve used this handy bit of code to add a message programmatically to a Validation Summary control, without associating it with a Validator. I’ve no idea where it came from – perhaps my head, perhaps someone cleverer than I... so if it was from you, shout up! I was asked how to do this today by a customer, so I felt inspired to blog it.

Anyway, sometimes you get an error from your business logic that it just isn’t practical to have pre-validated. For example, when adding a new employee to a database, perhaps the employee name has a UNIQUE constraint on it. Validating this up front might not be easy...

So if I get an error back from my business logic (either in the form of a list of validation errors, or in the worst case scenario as an exception) how do I display this message to the user? Well it turns out this is quite easy – just add a validator that is reporting itself as “IsValid = false” to the Page.Validators collection.

Consider the following class;

public class ValidationError : IValidator

{

private ValidationError(string message)

{

ErrorMessage = message;

IsValid = false;

}

public string ErrorMessage { get; set; }

public bool IsValid { get; set; }

public void Validate()

{

// no action required

}

public static void Display(string message)

{

Page currentPage = HttpContext.Current.Handler as Page;

currentPage.Validators.Add(new ValidationError(message));

}

(Note: This is using automatic properties - a C# 3.0 feature. Alter the code to use standard properties if you're using an earlier version of .NET)

This immediately allows me to use the following code;

ValidationError.Display("Oops, some error occurred.");

Succinct, eh?! Here’s a shot of it in action;

Loving LINQ

simonince — Tue, 30 Oct 2007 15:41:00 GMT

I have to say, I love how easy it is to do SQL-like expressions over collections of objects with LINQ...

If we have two simple classes that define our data;

class Person

{

public int Id { get; set; }

public string Name { get; set; }

public int AddressId { get; set; }

}

class Address

{

public int Id { get; set; }

public string Line1 { get; set; }

public string PostCode { get; set; }

}

Then we can “join” them in memory with a quick LINQ query;

static void JoiningCollections()

{

// create some test data

List<Person> people = new List<Person>()

{

new Person() { Id=1, Name="Simon Ince", AddressId=1},

new Person() { Id=2, Name="Someone Else", AddressId=1},

new Person() { Id=3, Name="My Friend", AddressId=2},

new Person() { Id=4, Name="My Other Friend"}

};

// create some more test data

List<Address> addresses = new List<Address>()

{

new Address() { Id=1,

Line1="1 Aroad",

PostCode="A1 B23" },

new Address() { Id=2,

Line1="3 Another Road",

PostCode="Z1 ZZZ" }

};

// define a really simple query

var results =

from p in people

join a in addresses

on p.AddressId equals a.Id

select new { p.Name, a.Line1, a.PostCode };

// and enjoy the simplicity of the results

foreach (var result in results)

{

Console.WriteLine(String.Format("{0} lives at {1}, {2}.",

result.Name,

result.Line1,

result.PostCode));

}

Imagine how many more lines of code you would have to write to achieve that before LINQ existed.

The one thing I don’t like about this is that you may need to avoid the “var” keyword when returning result sets to a calling function. No problem... just add a class that can pair up your names and addresses;

class PersonsAddress

{

public Person Person { get; set; }

public Address Address { get; set; }

}

... and change your query and output routine to use it;

IEnumerable<PersonsAddress> results =

from p in people

join a in addresses

on p.AddressId equals a.Id

select new PersonsAddress { Person=p, Address=a };

foreach (PersonsAddress result in results)

{

Console.WriteLine(String.Format("{0} lives at {1}, {2}.",

result.Person.Name,

result.Address.Line1,

result.Address.PostCode));

}

Hey presto – you have just joined together two sets of objects in memory, and could now return them as a strongly typed collection of data. What is also interesting is that by using the IEnumerable<PersonsAddress> type this query won’t be executed until you start to iterate over the results.

The only gotcha with this is that I dread the day when I see two massive collections of data retrieved from a database and joined in memory... so be careful! Bear in mind that in memory joins like this will almost certainly be slower than when done in an engine designed to do it all the time – SQL Server. I say almost as you could point out there is overhead to hit a database, and if you have two collections containing only a few items each I might be persuaded it is quicker to do it in memory... but you see my point, non?!

Still, you’ve got to love LINQ.

Two approaches to a LINQ Solution Structure

simonince — Mon, 29 Oct 2007 16:31:00 GMT

Background

I’m in the process of writing a small windows application with a very straightforward architecture, for which the only twist is the need to be able to plug in different data providers according to how it is used. This means it must be able to handle SQL 2005, other database servers, XML files, flat files, and any other data source that I choose during the life of the application.

Now this isn’t a complex requirement, and I’ve done it many times before, but what is key to the implementation is that I want to build my first data source to access a SQL 2005 database using LINQ to SQL. This means I thought for a while about the best way to take advantage of LINQ without compromising my plug-in architecture.

The simple diagram below should illustrate what I have in mind;

Obviously my Application and LinqDataSource assemblies will both have a reference to the Interfaces assembly, but there can be no other assembly references in this model.

There are 3 core concepts involved in my ideal architecture;

1. All communication is through interfaces defined in a separate assembly. This assembly contains both entity and operation definitions (the equivalent to Service Contracts and Data Contracts, should we be talking web services).

2. No implementation specific types may be in these interfaces.

3. The host application must have no knowledge of which implementation it is using (a specific instance of a data source should be created using Reflection based on values provided in configuration).

In contrast to this, LINQ to SQL provides some key benefits that I wanted to exploit;

1. It creates code for entities that reflect the tables defined in my database.

2. It handles optimistic concurrency, synchronising “identity” columns with the database, and so on.

3. It automatically tracks changes to the entities it creates so that the changes that must be written back to the database can be deduced easily.

4. It validates property values on the entities I create.

5. It allows me to use rich LINQ statements in code to select the data I want.

6. It has a very extensible model which would allow me to enhance the data access layer further (e.g. I could override validation methods on the entities).

Combining these lists leads me to the challenges;

· If LINQ to SQL automatically defines the entities in my LinqDataSource assembly this means I can’t reuse them across other data source implementations.

· I don’t want to have to do lots of entity translation (see Don Smith’s video on entity translation in the Web Service Software Factory if you’ve not heard this term) between business entities and database entities, as SQL is in reality my primary data source, and therefore the two contain the same logical fields.

The first of these challenges is the real stickler – I would normally define an entity in a shared interfaces assembly that all my loosely coupled plug-ins use. But LINQ to SQL is defining entities – so that means I’ll end up with many entity definitions, all very similar, and lots of entity translation between them all, right? Yuck. It is this I wanted to avoid if at all possible.

It turns out that rising to these challenges, and combining the two worlds of LINQ and my loosely coupled application architecture is actually very simple. So simple, in fact, I questioned whether I should write this post or not! But I decided in the end that it was indeed a useful illustration of how to approach such architecture, and of course, if I’d had to go through the thought process others would need to also. So, I came up with two slightly different approaches, and could not decide between them – each captured my imagination for its elegance and simplicity, and each has distinct advantages...

To approach this problem we’ll look at the top and bottom of the architectural layers first, and then decide how to knit the two together.

The Database

Starting with the lowest layer, then, imagine my application is based on a very simple database named Employees – in fact so simple it has only a single table, as shown below;

As a result of this, the LINQ to SQL designer will generate two useful classes. “EmployeesDataContext” is effectively a facade to the database, allowing us to execute queries and commands against an in memory representation of the data before committing the changes, and “Employee” is an entity that represents a row of data in our Employee table. Examining the designer generated C# for Employee (by looking in the “.designer.cs” file under your LINQ to SQL “.dbml” file) reveals how the properties reflect the fields in the table

[Table(Name="dbo.Employee")]

public partial class Employee :

INotifyPropertyChanging,

INotifyPropertyChanged

{

private int _Id;

private string _Name;

private string _JobTitle;

private byte[] _Timestamp;

// other members ommitted...

}

The Interface Definition

So jumping back up the layers to the application layer, we can define what operations and entities we need. My application operates in a very CRUD manner, so the obvious operations I will require are “Get All”, “Get By Identifier”, “Insert”, “Update”, and “Delete”. I can also confirm that the application must be able to display an employee’s Name, Job Title, and internal system identifier. These requirements result in two simple interface definitions;

public interface IEmployee

{

int Identifier { get; }

string Name { get; set; }

string Title { get; set; }

}

public interface IEmployeeDataSource

{

IEmployee GetById(int id);

List<IEmployee> GetAll();

void Insert(IEmployee employee);

void Update(IEmployee employee);

void Delete(IEmployee employee);

}

There is one important thing to notice here – that being that the fields on IEmployee do not precisely match those on the Employee table. The Timestamp column is not present, as I don’t need it in the User Interface, and I have used slightly different property names for “Id” and “Job Title”. I have done this deliberately as the chances are in a real world situation there will be some mismatch between the two, especially if different teams or even companies are authoring each component.

The Glue: Option 1 (Adapters)

My first thought was to create an Adapter class to connect IEmployee to the Employee LINQ entity. Such a solution can be described rather succinctly in UML;

An example of how this might work is shown below;

public class EmployeeAdapter : IEmployee

{

private Employee _employee;

public EmployeeAdapter()

{

_employee = new Employee();

}

internal EmployeeAdapter(Employee employee)

{

_employee = employee;

}

internal Employee Employee

{

get

{

return _employee;

}

public int Identifier

{

get { return _employee.Id; }

}

public string Name

{

get { return _employee.Name; }

set { _employee.Name = value; }

}

public string Title

{

get { return _employee.JobTitle; }

set { _employee.JobTitle = value; }

}

This adapter simply maps calls to properties on IEmployee to the corresponding properties on Employee. Such an adapter allows us to write some pretty simple code in an implementation of IEmployeeDataSource to retrieve and persist our data;

public IEmployee GetById(int id)

{

return ( from c in Db.Employees

where c.Id == id

select new EmployeeAdapter(c)).SingleOrDefault();

}

public List<IEmployee> GetAll()

{

return Db.Employees.Select(

e => new EmployeeAdapter(e) as IEmployee

).ToList<IEmployee>();

}

public void Insert(IEmployee employee)

{

EmployeeAdapter adaptedEmployee = employee as EmployeeAdapter;

if (adaptedEmployee == null)

throw new ArgumentException("Wrong type.");

Db.Employees.Add(adaptedEmployee.Employee);

}

public void Update(IEmployee employee)

{

EmployeeAdapter adaptedEmployee = employee as EmployeeAdapter;

if (adaptedEmployee == null)

throw new ArgumentException("Wrong type.");

// no update action required

}

public void Delete(IEmployee employee)

{

EmployeeAdapter adaptedEmployee = employee as EmployeeAdapter;

if (adaptedEmployee == null)

throw new ArgumentException("Wrong type.");

Db.Employees.Remove(adaptedEmployee.Employee);

}

There are some interesting points to examine in this implementation. Note the presence of the second “internal” EmployeeAdapter constructor that takes an Employee entity as an argument. This is to allow the data access framework to wrap results in an EmployeeAdapter, for example when retrieving a list by ID;

return ( from c in Db.Employees

where c.Id == id

select new EmployeeAdapter(c)).SingleOrDefault();

The embedded LINQ statement must construct a new EmployeeAdapter around each result. The syntax also gets a bit confusing when retrieving all records;

return Db.Employees.Select(

e => new EmployeeAdapter(e) as IEmployee

).ToList<IEmployee>();

Each result must be wrapped with an EmployeeAdapter, and then explicitly cast to an IEmployee to ensure that LINQ detects the correct return type of List<IEmployee>. Without the explicit cast of the EmployeeAdapter to an IEmployee, LINQ returns a List<EmployeeAdapter>, which cannot be cast to the method’s declared return type of List<IEmployee>.

This approach follows well published patterns (namely Adapter), but some of the syntax seems a little untidy, and I have introduced a class that must be maintained to synchronise the implementation of an interface and an entity. So that’s three different types that all need synchronising! I thought about this a little more, and came up with...

The Glue: Option 2 (Partial Classes)

LINQ to SQL uses partial classes for most of the code it generates. This allows you to add functionality to the entities that have been generated by the designer, without concern about these additions being overwritten by the designer at any point, and allowing you to use clearly defined extension points. These extension points are way beyond the scope of this article, but trust me, they are there J

Creating the “other half” of the partial Employee entity class generated by LINQ to SQL gives us the opportunity to directly implement IEmployee on the Employee entity. Adding a file to the solution with the following content, we can see that the Adapter pattern described in Option 1 has now been merged with the implementation of Employee.

public partial class Employee : IEmployee

{

public int Identifier

{

get { return Id; }

}

public string Title

{

get

{

return JobTitle;

}

set

{

JobTitle = value;

}

Note that there is no Name property defined in this class. Why not? Because Employee already defines Name, as it was generated by the LINQ to SQL designer (for this field both the interface definition and database agree on the precise naming), so there is no need to implement it again. Obviously the closer your database definition and interface definition are, the less work you need to do here!

This has two really significant impacts;

1. It has the potential to simplify and reduce maintenance. If all the fields on IEmployee and Employee were named the same, all the partial type need contain is a declaration that it implements the interface – and no members at all!

2. Now the LINQ Employee entity itself implements the interface, the casting syntax we found when using the adapter pattern is significantly more simplified.

The UML for this approach shows exactly how simple it has become, just by exploiting a by-design feature of LINQ;

If we now examine our IEmployeeDataSource implementation, we can see how some of the syntax has simplified;

public IEmployee GetById(int id)

{

return ( from c in Db.Employees

where c.Id == id

select c

).SingleOrDefault();

}

public List<IEmployee> GetAll()

{

return Db.Employees.Select(e => e as IEmployee).ToList<IEmployee>();

}

// other methods ommitted...

The differences are most obvious when retrieving data. There is no longer a need to wrap each returned entity in an adapter – as the entity is the interface implementation as soon as it is retrieved from the database. The only casting that is performed is to ensure that LINQ creates the correct return type array in “Get All” (List<IEmployee>).

Cleaning up for LINQ

Both of these options are viable alternatives for the application architecture in question – but there are a few loose ends that apply to both options!

You may have noticed earlier on... how come the “Update” method has a “no action required” comment? Surely you need to write changes to the database?

It is important to understand what all the write methods are really doing here – Insert, Update, and Delete all operate on LINQ’s in-memory model of the database. Although the code for Insert looks like the changes have been written out to the database, they haven’t. In fact, if you use the code above, no database changes will ever be written!

One of the big benefits to avoiding entity translation is that the real bona-fide LINQ entity is the object that the calling application will perform operations on. This means that all that LINQ provides is automatically supported... and one of those provisions is tracking when objects change. Therefore when a user calls Update, LINQ already knows the object has changed, so we needn’t do anything; it is already flagged for writing to the database at a later date. So why bother with an Update method at all? Well, this is a generic interface that must support other data storage technologies in the future – such as XML for example – and these data sources most likely won’t auto-track changes to entities. Just another reason to use LINQ I suppose!

So we’ve just shown that we don’t yet write to the database – so how do we force this to happen? We must add a “CommitChanges” method to the IEmployeeDataSource interface, implemented as follows;

public void CommitChanges()

{

Db.SubmitChanges();

}

SubmitChanges just tells LINQ to persist any Inserted, Updated, or Deleted changes to the database. It will of course automatically determine the Identifier for any newly inserted records, and so on.

The final question is – how do I create a new record? Consider the following code;

private void InsertRecord(

IEmployeeDataSource source,

string name,

string jobTitle)

{

IEmployee record = new IEmployee();

record.Name = name;

record.Title = jobTitle;

source.Insert(record);

source.CommitChanges();

}

Of course, you can’t create a new instance of an employee using the syntax “new IEmployee()”! And it turns out this is good – if we want our entity to be fully LINQ aware, it must be a fully-fledged LINQ entity from the start. When using the Adapter pattern, we must ensure that the EmployeeAdapter has a valid Employee entity encapsulated within it.

Therefore, creation of new entities must be a responsibility that is delegated to the concrete implementation of an IEmployeeDataSource – such that for my LINQ data sources, I get an entity that supports LINQ, and for a future XML data source I may need one that supports XML (perhaps it stores an XmlNode reference in the same way as EmployeeAdapter stores an Employee reference).

I have chosen to use the Factory Method pattern to achieve this, and therefore have added a CreateNew method to the IEmployeeDataSource definition (the final complete definition follows to save you tracing the additions throughout this article);

public interface IEmployeeDataSource

{

IEmployee CreateNew();

IEmployee GetById(int id);

List<IEmployee> GetAll();

void Insert(IEmployee employee);

void Update(IEmployee employee);

void Delete(IEmployee employee);

void CommitChanges();

}

The implementation of this new method couldn’t be simpler. For Option 1, we return an EmployeeAdapter as follows;

return new EmployeeAdapter();

... and for Option 2 we simply return an Employee;

return new Employee();

Finally, then, our logic to insert a new employee is tweaked to use our new entity factory;

private void InsertRecord(

IEmployeeDataSource source,

string name,

string jobTitle)

{

IEmployee record = source.CreateNew();

record.Name = name;

record.Title = jobTitle;

source.Insert(record);

source.CommitChanges();

}

And that’s it! I hope that has been useful – we have seen how you can use LINQ in your applications even when the coupling between the entity consumer and your data access layer must be weak, we have seen some Object Oriented patterns in practice, and we have seen how to take advantage of the most basic of LINQ’s extensibility model.

Note: Yes, I know this is a lot of text to tell you to write a class that implements an interface; but like I said at the beginning, it’s the journey that counts, and I hope you agree!