Saturday, September 10, 2011

Intro to Expressions

I've been doing a lot of work with Expressions recently and completely love working with them. I feel that they allow your code to be more powerful as well as more expressive. It seems to me that many developers don't use Expressions in their code though. Maybe that is because Expressions can seem daunting. If this is the case I figured some of you might like a walk through of how you can use Expressions in your daily development.

What will we be building today? How about the beginnings a validation-helper for ensuring that a field, property, or argument is not null? How often have you written the following code?



Now this code is all good and well. But at some point we might change the name of the parameter but forget to update the string that represents the name of the parameter. Instead we can use an Expression which will dynamically get the name of the member which guarantees that the argument name provided to the ArgumentNullException constructor is always correct. So instead of using a string to represent the argument name, let's use an Expression:


Nice and simple! Now for some Expression basics.

Expression Basics

As seen on msdn the System.Linq.Expression namespace can be explained as follows:
The System.Linq.Expressions namespace contains classes, interfaces and enumerations that enable language-level code expressions to be represented as objects in the form of expression trees.

The abstract class Expression provides the root of a class hierarchy used to model expression trees.

The classes in this namespace that derive from Expression, for example MemberExpression and ParameterExpression, are used to represent nodes in an expression tree. The Expression class contains static (Shared in Visual Basic) factory methods to create expression tree nodes of the various types.

The enumeration type ExpressionType specifies the unique node types.

I think that's enough of that for now. Let's dive into some code.

Following is what our method might look like without utilizing Expressions.



As we will be passing properties, fields, and method parameters into our IsNotNull method, we will be dealing exclusively with Expressions of type MemberExpression.
The best tool in the Expression toolbox is the ExpressionVisitor. In a nutshell an ExpressionVisitor handles the navigation and of an ExpressionTree (which we will talk about in more detail in my next post).

To handle extracting the MemberExpressions from our ExpressionTree we will create an ExpressionVisitor and override the VisitMember method. The VisitMember method will simply add the MemberExpression to a SortedList instance. The reason for using a SortedList is that a single Expression Tree can contain many Expressions. In some scenarios the order of which the Expressions are extracted can be very important.Here is our CustomExpressionVisitor implementation:


Now that we have a method of extracting a MemberExpression, we can implement our IsNotNull(Expression>) method. This method must do the following:
  1. Extract the MemberExpression
  2. Extract the value of the property, field, or argument from the MemberExpression
  3. Check if the value is null
  4. If null, throw an ArgumentNullException

Here is the finished code for the Validate class:


And finally here is an example of how to invoke IsNotNull:


Source code can be downloaded from github here.
























Tuesday, February 15, 2011

Visual Studio Light Switch

As is typical for me I went to MSDN and saw a quick blurb about Visual Studio Light Switch. I had never heard of it before and so was interested to see what it was all about. Basically, it is a new platform for easily and quickly creating professional-quality business applications for the desktop, the web, and the cloud. I think it looks to be absolutely amazing! I'm not sure where they are going with it but I could definitely see Light Switch being a much more powerful (and much more professional-looking) replacement for ASP.NET Dynamic Data.

I have used Dynamic Data several times and have found it to be invaluable. That being said, it doesn't offer some of the integration with SharePoint and Office. Additionally, the look and feel of the Light Switch apps is really outstanding. Plus, you can use your Light Switch app on the web or on the desktop! That's just awesome!

If you haven't seen anything on Light Switch check out the website and click on "Watch Videos about Light Switch".

I really suggest watching the keynote video (50+ minutes) if you want to see some really powerful stuff!

Monday, February 14, 2011

Asshole Driven Development

Shai Raiten had a great blog post about A-s-shole Development.

"Driven development (ADD) – Any team where the biggest jerk makes all the big decisions is asshole driven development. All wisdom, logic or process goes out the window when Mr. Asshole is in the room, doing whatever idiotic, selfish thing he thinks is best. There may rules and processes, but Mr. A breaks them and people follow anyway."

I've worked with people like this before and almost fell out of my seat laughing when I saw this!

Saturday, February 5, 2011

Generics and casting

I often find myself creating methods which return a generic type.  For instance, on a recent project I have been dealing with a lot of XML.  Instead of casting the value of an XAtrribute to an int or a decimal in a bunch of places in my code I created an extension method which will handle the dirty work.





This pattern is something I find myself coming back to constantly.  Hopefully you'll find some use for it.

Friday, February 4, 2011

Different types of coupling

A co-worker of mine (the one and only Dan Robinson) sent around an email to our team talking about different types of coupling between systems.  I'll post the bullet points here:



  • Afferent – who calls this system?  A system with high afferent coupling is hard to replace
  • Efferent – who does this system call?  A system with high efferent coupling has a lot of dependencies
  • Platform – do both systems have to be on the same platform?  Levels of interoperability…
  • Spatial – how much do systems know about each other’s location?  If the topology changes, do things break?
  • Temporal – how much do things wait for each other?  If one system slows down, how are other systems affected?
I know this is a quick post but I feel better knowing that I got it out there.  I don't know about you but this is one I will keep coming back to.