CodeBetter.Com - Stuff you need to Code Better!

More signs of FubuMVC getting real

Jeremy D. Miller — Tue, 09 Feb 2010 14:52:00 GMT

Just launched last night: http://guides.fubumvc.com/. The main page has been around for a couple weeks now at http://fubumvc.com/.

It's not that much yet, but I think the existence of *any* documentation at this point is a good indication that we're serious about making the FubuMVC reboot take off.

If you're interested in getting involved, there's a TODO list that Chad & I are trying to keep up with ideas for extending FubuMVC at http://wiki.fubumvc.com/TODO and the developers list is at http://groups.google.com/group/fubumvc-devel.

VS 2010 RC1 available on MSDN

Patrick Smacchia — Tue, 09 Feb 2010 11:05:00 GMT

... and this RC1 will go public in 3 days. (if your are logged in MSDN, the link is: https://msdn.microsoft.com/en-us/subscriptions/securedownloads/default.aspx?pv=18%3a370)

I had access to the Release Candidate 1 limited community editions for a month, and I can say that hopefully, overall stability, performance and memory consumption have been greatly enhanced. As many, I was pretty angry with VS2010 beta2 performance and stability and it is good to see that MS engineers were able to address all these.

Also, a huge thanks to the Visual Studio Partners team that was pretty responsive and efficient during the last weeks. Thanks to their help, NDepend v3 beta3, I announced 12 days ago, works 100% with this VS 2010 RC1 version.We hope to have a NDepend v3 Release Candidate during next week.

Also, we prepared a screencast overview tour for this upcoming release integrated in Visual Studio 2010, 2008 and 2005. The fun part was that we used a synthesized English speaker for the speech in the screencast (it is Ryan US in the combo box). The reason is that in our team, we all have more or less strong French accent (I would say more for me, you can get a glimpse in this podcast with Scott Hanselman). (Tip: if you want to make your girlfriend or wife laugh, just type something sweet and make it say with the synthesized speaker ).

Exploring MongoDB with F#

Matthew.Podwysocki — Tue, 09 Feb 2010 06:15:21 GMT

If you’ve been following me on Twitter, I’ve been digging a bit into MongoDB. When I was involved with the planning of NoSQLEast this past year, I sat down and used it in anger and was quite pleased with the results. Using it with a language which allows for quick prototyping such as F# has afforded me to get up and going on a project with very little effort. At some point, I don’t want to be bothered with having to go into another tool, create a schema, decide what data types, run migrations and all the fun things that come along with traditional RDBMS solutions. I just want a quick answer with the data I have. There was one issue of course that nagged me which was the ubiquitous use of strings for everything from databases, collections, and keys. With a language such as F#, could we do any better than this approach?

From Dictionaries

Before we look at any potential solution, let’s first look at how we insert a document using the normal string approach with the C# MongoDB Driver. Let’s take books for a potential book reviewing system as an example. Let’s first insert a document into the collection.

open MongoDB.Driver

let mongo = new Mongo()
if not <| mongo.Connect() then
  failwith "Could not connect to MongoDB instance"
  
let books = mongo.["BookReviews"].["Books"]

// Insert a book
let book1 = new Document()
book1.["Title"] <- "Programming F#"
book1.["Authors"] <- ["Chris Smith"]
book1.["Publisher"] <- "O'Reilly"
book1["Rating"] <- 5.0

books.Insert(book1)

In the code above, I connected to the MongoDB instance I have running locally. After that, I browse to the BookReviews database and then to the Books collection. What’s interesting about that last piece is that if it doesn’t exist already, MongoDB will create it for me, so that saved me quite a bit from having to go into another tool, create a database, define columns, set indexes, etc. After I get the Books collection, I then create a new Document with some keys and insert it into the collection. Now, how about querying? Let’s say I want to get all books by O’Reilly publishing. How would I do it?

let oreillyQuery = new Document()
query.["Publisher"] <- "O'Reilly"

let oReillyBooks = books.Find(oReillyQuery)
printfn "O'Reilly books %d" Seq.length oReillyBooks.Documents

if not <| mongo.Disconnect() then
  failwith "Could not disconnect from MongoDB instance"

As you can see from the code above, we simply need to create a query document and set the appropriate keys. Then we use the books collection to find it based upon our query. Overall, it’s a great experience, but that’s an awful lot of string usage, more than my taste usually allows. What can we do about it?

To Dynamic

As we covered in the previous post, F# has added support for both a dynamic get ( ? ) and set operator ( ?<-). Note, that I said support and not actual implementation. The actual implementation is up to you and your need. There are a couple of solutions that we could explore on making our lives easier with this operator. Ultimately, our goal is to look something like the following:

let mongo = new Mongo()
if not <| mongo.Connect() then
  failwith "Could not connect to MongoDB instance"

let books = mongo.["BookReviews"].["Books"]

let book = new Document()
book?Title <- "Real World Haskell"
book?Authors <- ["Bryan O'Sullivan"; "John Gorezen"; "Don Stewart"]
book?Publisher <- "O'Reilly"
book?Rating <- 4.6

books.Insert(book)

if not <| mongo.Disconnect() then
  failwith "Could not disconnect from MongoDB instance"

Or better yet, rid ourselves of the strings altogether such as BookReviews and Books. One solution could be to use the incoming type in the ? operator to be an IDictionary as the MongoDB C# Driver Document class is based off an IDictionary.

open System.Collections

let (?) (this : IDictionary) key =
  this.[key]

let (?<-) (this : IDictionary) key value =
  this.[key] <- value

This will allow for our calls to the document to be just as I wanted in the beginning. But, that doesn’t cover how I could possibly cover the case for getting our database and our collection. One common thread between the two of them is the indexed property of Item. With that in hand, we could revisit the idea of using member restrictions to model this dynamic lookup of both gets and sets. Let’s look at the code required for setting these member restrictions.

let inline (?) this key =
  ( ^a : (member get_Item : ^b -> ^c) (this,key))
 
let inline (?<-) this key value =
  ( ^a : (member set_Item : ^b * ^c -> ^d) (this,key,value))

This gives us not only the ability to deal with our Documents much as we had above, but also change our calls to get our database and collection, such as:

// Old
let books = mongo.["BookReviews"].["Books"]

// New
let books = mongo?BookReviews?Books

But, ultimately, as I pointed out in the last post, this has potential problems due to the nature of how F# treats the get_Item and set_Item properties. For example, this solution does not work quite well with LINQ, such as the following will return an error.

let d = [dict [("dynamic", 123)];  dict [("dynamic", 456)]]

let allDynamics =
  query <@ seq { for m in d.AsQueryable() do
                   yield m?dynamic } @>
                   
val alllDynamics : seq<int> = Error: Specified method is not supported.

The previous example of using IDictionary/IDictionary<’Key,’Value>, however, does work in this scenario. What about the DynamicObject approach? As Scott Watermasysk described in his post on MongoDB and C# Dynamics it certainly is possible for us to take advantage of a DynamicObject with TryGetMember/TrySetMember defined. But, how in F# could we take advantage of that? I hope to cover that soon enough.

Conclusion

MongoDB has been a great source of inspiration for me lately as I look at Not Only SQL solutions. Not having to worry about migrations, schemas, data types and the likes, I’ve been able to be quite productive in prototyping ideas, and getting answers quickly. In addition, with a language such as F# where we can instantly get feedback through our REPL, it adds another dimension to trying out new solutions.

With the flexibility of the F# language, we’re able to get some sort of syntactic sugar which allows us to make MongoDB look and feel much like we’re in LINQ to SQL without even the need for the dynamic bindings that are coming in .NET 4.0.

Using and Abusing the F# Dynamic Lookup Operator

Matthew.Podwysocki — Fri, 05 Feb 2010 21:18:56 GMT

Lately, I’ve been playing with such things as MongoDB using F# to rapidly prototype ideas. With that, I’ve tried to rid myself of magic strings by using the F# dynamic lookup operator. I’ll cover exactly what I’m doing in the next post when using MongoDB, but in this post I’d like to explore a little of what you could do with a little noticed dynamic lookup operator in F#.

The Dynamic Lookup Operator

Much like C# 4.0 has the ability to do dynamic lookup, F# also has the same capability, although in a different capacity. The language has support for a dynamic lookup get operator ( ? ) and set operator ( ?<- ), but note that I said support and not actual implementation. The actual implementation is up to you and how you want to use it.

The Get Operator

Let’s start off by implementing the get operator to get a public property (not super useful yet).

let (?) (this : 'Source) (prop : string) : 'Result =
  let p = this.GetType().GetProperty(prop)
  p.GetValue(this, null) :?> 'Result

We can write an example that verifies the behavior such as comparing a normal invocation and our “dynamic” invocation, as in this example of comparing getting the length of a string.

[<Fact>]
let ``Dynamic lookup should equal normal``() =
  areEqual "foo".Length "foo"?Length

But, we’re not limited to that. For example, we could instead decide that we want to get a private member instead of a public one. We could change up our example from above just slightly.

let (?) (this : 'Source) (prop : string) : 'Result =
  let flags = BindingFlags.GetProperty |||
              BindingFlags.NonPublic
  let p = this.GetType().GetProperty(prop, flags)
  p.GetValue(this, null) :?> 'Result

We can verify our behavior of this idea with a little example, for example invoking a private property in a custom class such as the following:

type PrivateProperty(propValue : string) =
  member private __.PropValue
    with get() = propValue
    
[<Fact>]
let ``Can invoke private property``() =
  let expected = "foo"
  let p = PrivateProperty(expected)
  
  let actual : string = p?PropValue
  
  areEqual expected actual

So, as you can see, this is quite useful so far, but we’ve only scratched the surface. We’ve just dealt with properties so far, but what about methods? The same applies here as well. In this instance, let’s take a method that could have any number of arguments and invoke it just as if we would normally.

open Microsoft.FSharp.Reflection
open System.Reflection

let (?) (this : 'Source) (member' : string) (args : 'Args) : 'Result =
  let argArray =
    if box args = null then null
    elif FSharpType.IsTuple (args.GetType()) then
      FSharpValue.GetTupleFields args
    else [|args|]

  let flags = BindingFlags.GetProperty ||| BindingFlags.InvokeMethod
  this.GetType().InvokeMember(member', flags, null, this, argArray) :?> 'Result

What we needed to do here is take not only the member but the arguments as well. If the arguments object is null (or unit), then we pass a null objet array, else if our type is a tuple, then we create an array from our tuple, and finally if it’s a single argument, then we make it into an array. Finally we invoke our member with the flags to say it is either a property getter or a method and invoke with our arguments. Let’s write an example of how to use this.

[<Fact>]
let ``Can invoke method with dynamic lookup``() =
  isTrue ("dynamic"?Length() > 0)
  isTrue ("dynamic"?EndsWith("ic"))
  areEqual "dyn" ("dynamic"?Substring(0,3))

Above are three tests which show no arguments, a single argument, and finally tupled arguments. But what about setters?

The Set Operator

Just as we have the ( ? ) operator reserved for the get operator, we have the ( ?<- ) operator reserved for the set. This allows us to be able to set any number of things with the same ease as the get. For example, we could set a public property:

let (?<-) (this : 'Source) (property : string) (value : 'Value) =
  this.GetType().GetProperty(property).SetValue(this, value, null)

This simply gets the property and then sets the appropriate value. And then we can write a test as an example of how it should work.

type MutablePropertyClass(value : string) =
  let mutable v = value
  
  member __.Value 
    with get() = v
    and  set(value) = v <- value
    
[<Fact>]    
let ``Dynamic setter should set property``() =    
  let m = MutablePropertyClass("foo")
  
  m?Value <- "dynamic"
  
  areEqual "dynamic" m.Value

In this example, we have a simple class with a property with a getter and setter and then we set our property using our special operator and then compare the values. Once again, this is flexible enough where we could set private properties much as we retrieved them above. Now, let’s put them together for a few quick examples.

The Dictionary Example

One idea that we could go with is instead of using string keys for dealing with key value pairs, we could use our dynamic getter and setter instead. Nothing like a bit of syntactic sugar to brighten your day to lessen the noise. Our goal for this is to go from:

let d = Dictionary<string,obj>()
d.["StaticKey"] <- "Meh"

To something like the following:

let d = Dictionary<string,obj>()
d?DynamicKey <- "Totally!"

How could we pull this one off? Well, we could implement the dynamic lookup getter and setter to do nothing more than look in the dictionary as follows:

open System.Collections

let (?) (this : #IDictionary) key =
  this.[key]

let (?<-) (this : #IDictionary) key value =
  this.[key] <- value

Now we can verify our behavior with our test that we should have written first.

let ``Dictionary should get and set dynamically``() = 
  let d = Dictionary<string,obj>()
  
  d?DynamicKey <- "hello"
  
  areEqual d.["DynamicKey"] d?DynamicKey

A solution like this could work well for situations like MongoDB, which we’ll get into with our next post. But, could go a step further and to say anything with the Item property could be ours for the taking.

The Item Indexer Property Example

In the .NET libraries, we have a few classes which expose an indexer property like an array, a Dictionary, and even a string. It would be nice to have a way to both get and set this value through the use of our dynamic lookup operator, but how could we pull this off? In some previous posts, I talked about generic restrictions in the F# language, and one in particular stands out, the member restriction operator. This operators lets us constrain a given object parameter so that it must implement the following methods and properties.

Remember, our overall goal is to support calling this:

open System.Collections.Generic

let d = Dictionary<string,string>()
d?DynamicKey <- "Totally!"

type IndexedObject() = 
  let d = Dictionary<string,string>()

  member self.Item
    with get(key) =
      d.[key]
    and set key value =
      d.[key] <- value
      
let i = IndexedObject()
h?IndexedKey <- "IndexedValue"

So, what we have is both a Dictionary<TKey,TValue> and a custom indexed object. Since they do not follow an inheritance chain which exposes an Item property, we cannot use the example from above with the IDictionary. Instead, we’ll use member restrictions for both the method get_Item and set_Item.

let inline (?) this key =
  ( ^a : (member get_Item : ^b -> ^c) (this,key))
 
let inline (?<-) this key value =
  ( ^a : (member set_Item : ^b * ^c -> ^d) (this,key,value))

What you see is that we’re calling both the get_Item and set_Item properties, which are the raw method names for the Item property. Now we’re able to verify our test using our IndexedObject class from above:

let ``Can use dynamic indexed getter and setter``() =
  let i = IndexedObject()
  
  i?SomeKey <- "Some value"
  
  areEqual i.["SomeKey"] i?SomeKey

A big word of caution when using this approach is that you’ll get a nice warning from the F# compiler that doing this may cause unverified code as F# treats the Item property specially. For example, all value types must be boxed before putting them into the collection.

let h = Hashtable()
h?MyKey <- 3 // Don't do this

h?MyKey <- box 3 // Do this

Very powerful way of doing things but also you must be careful with this approach if you use it at all.

Conclusion

So, as you can see, F#, just like C# has the facilities for dynamic lookup, although in F# you are left to implement it yourself in any which way you like. One great thing about these operator is that it doesn’t require .NET 4.0 to implement and use them. But with any power comes of course some responsibility for it, so use it wisely.

Scoop: Reflector v6 pro RTM to be released by the 15th of this month

Patrick Smacchia — Fri, 05 Feb 2010 15:38:00 GMT

This is really exciting time these days. Most of .NET tooling vendors are about to provide a major upgrade of their products within the next weeks. And Reflector is part of the lot! A brand new version, Reflector v6, is about to be go live RTM on Monday 15th of February 2010. This will be the first time the company Red-Gate will update the product since it has been acquired from its original creator, Lutz Roeder, in August 2008.

There are 90% of chances you are using Reflector daily so don't be afraid: current Reflector features will continue to be provided in a free version of the tool. The Red-Gate strategy is to append new innovative features to the tool, and only these features will require a professional purchased version. The flagships features of Reflector v6 is the ability to debug source code decompiled from IL code, in the Visual Studio debugger. This is certainly a killer one: we all need at a point to have a better understanding of what's happening at runtime in Framework used by our code.

Having used Reflector v6 beta, I can say that plenty of cool featurettes have been also been added, including a bridge between Reflector and Visual Studio (ok this one is already provided more or less by several tools, including TestDriven.NET and NDepend)

Another cool thing is that the upcoming NDepend v3 is working hand-in-hand with Reflector v6 (as a Reflector addin). And as NDepend v3 is also a Visual Studio 2010 / 2008 /2005 addin, all NDepend features constitute more glue between Reflector v6 and Visual Studio, including:

from Reflector to Visual Studio
- Generating dependency graph and dependency matrix
- Generating CQL queries
- Opening Source files definition

from Visual Studio to Reflecor
- Opening a code element (assembly, namespace, type, method, field) in the Reflector class browser
- Decompiling a code element in a source file in any language supported by Reflector (IL, C#, VB.NET, MC++I, Oxygen, Delphi)
- Decompiling an older and a newer version of a code element in 2 text files, and comparing the 2 text files with your preferred diff tool.

StructureMap 2.6 (and 2.5.4) is Released!

Jeremy D. Miller — Thu, 04 Feb 2010 15:14:00 GMT

Time flies when you’re having fun. It’s been almost a year since I’ve made an official StructureMap release, so I guess it’s about time. This morning I uploaded the binaries for the 2.6 release. This release just adds some bug fixes and a couple minor additions to the 2.5.4 release that I made in December but didn’t really publicize. The release notes below are long, but that’s because they represent almost a year’s worth of development. As I said yesterday, StructureMap is most likely moving to GitHub with the documentation going as well. After a massive effort to write documentation early last year, huge chunks of it is already obsolete and there’s been a lot of addition since. I’m hoping that the move to the Wiki will make it easier to keep the docs up. In the meantime, I’ll try to blog a bit about the newer pieces starting tomorrow.

A tiny bit of history. This is the 11th StructureMap release since it debuted way back in June of 2004. Almost nothing is the same. We use it differently, the expectations are different, and very, very little of the original code survives today. At QCon San Francisco in 2008 I talked about what I’d learned from evolving this codebase over so many years and changes.

This release includes a lot of patches from the community, and I’d like to thank all of you for that – especially Frank Quednau and Andreas Ohlund for taking on some nastier things. Josh and Kevin Miller do yeoman duty answering StackOverflow questions (so I don’t have to).

What’s Changed?

New terse, “jQuery-esque” syntax for the Registry DSL. Let’s just write off “ForRequestedType<IFoo>().TheDefault.Is.OfConcreteType<Foo>()” as a well meant experiment, shall we? It’s still in the codebase, but it’s marked as [Obsolete]. Nobody liked it and I thought it was annoying in real life usage. Now, just do: For<IFoo>().Use<Foo>(); My whole goal was to reduce friction. Needs a big blog post
Changed the Registry DSL to make inline dependency configuration be more consistent. Definitely a blog post.
The “CreateProfile” syntax has gotten a lot of complaints for being inconsistent with the rest of the Registry DSL. I basically rewrote it to now be consistent with the “For<>().Use()” syntax in the main Registry DSL. Blog post coming soon….
Nested Container feature for short lived transactional requests. I built this for Dovetail usage, but I think it’s my preferred way to manage object scoping in certain circumstances. I mentioned it just a little bit in my NHibernate w/ StructureMap post a couple weeks back. Blog post coming soon…
The “Model” feature was completely redone. There’s a lot more power, and you can use it to pull services out of the Container and completely remove services from the Container as well. Sigh. Needs a blog post.
Convention based type registration got a lot of work. People are pushing this feature very hard and it had to grow. You can now use the Registry DSL to write conventions. This was improved farther in the latest code drop. Yeah, blog post coming…
Better support for registering services by Type objects for cases when you don’t necessarily know the Type upfront. Big request from several framework authors like Caliburn.
A helluva lot of new features to make working with open generic types easier. Jimmy Bogard blogged about some of it here. I’d like to show how StructureMap’s new features would make writing something like Davy Brion’s Agatha framework a snap. I use this stuff extensively inside of StoryTeller.
Added the lazy Func<T> feature from Autofac. A really great (and cheap) way to support lazily initialized components. Blog post coming.
Completely ditched all Reflection.Emit code. StructureMap now strictly uses dynamically constructed Expression’s that are pre-compiled into cached Func’s. I don’t know if that really makes much difference to users, but it makes StructureMap much, much easier to extend. The container does spin up faster with this mechanism. Makes me happy.
Supports IList<T> and List<T> arguments. It works just like Arrays. That’s been a while coming.
You can set the lifecycle from <AddInstance> if you happen to still use Xml configuration.
The “Lifecycle” code was completely reworked to eliminate shared code
Container.Dispose() was introduced. I’ve put a lot of effort into making StructureMap clean up after itself. Definitely a blog post coming.
ObjectFactory.Container. Slowly, but surely, I’d like to wean people away from using ObjectFactory too much in favor of scoped Container objects. I will NOT be further extending the ObjectFactory static methods to synchronize it with IContainer. Instead, I’m just exposing the ObjectFactory.Container property.
New abilities for IContext like BuildUp() (thanks to Kyle Malloy), getting all instances, and TryGetInstance
TryGetInstance() from Josh
Killed StructureMapConfiguration. Good riddance.
“Forwarding” requests for IFoo to whatever IBar is

Business Primitives (2/2)

drusellers — Thu, 04 Feb 2010 11:18:50 GMT

Ok, so now that we have talked about the Business Primitive concept lets go through some of the actual examples. Let's take an example of a 'Loan' class.

public class Loan
{
    public int Id { get; set; }
    public int InterestRate { get; set; }
    public DateTime TradedOn { get; set; }
    public DateTime SettledOn { get; set; }
    public decimal Principal { get; set; } 
}

After some small tweaks.

public class Loan
{
    public int Id { get; set; }
    public Rate Interest { get; set; }
    public DateTime TradedOn { get; set; }
    public DateTime SettledOn { get; set; }
    public Money Principal { get; set; }
}

Already the code feels more robust to me. The dates aren't that interesting to the business other than they are dates so they haven't yet been uplifted into 'business primitives' but Interest has been converted to 'Rate', which immediately helps with math and providing meaningful math like methods, as well as Principal which is now 'Money' which also helps with math and the more pernicious rounding issues.

So how was 'Rate' implemented? What does it look like?

[DebuggerDisplay("{_rate}%")]
public class Rate
{
    int _rate;
    private Rate() { }
    
    //factory methods
    public static Rate FromWholePercent(int rate) { new Rate(){_rate = rate};}

    //equality overrides here
    //operator overrides here
}

First, we have the 'DebuggerDisplay' attribute which is my new best friend, it allows you to customize how the debugger displays your object in the debug view, very helpful. I have wrapped the previous rate value in a very simple fashion, and now we have a nicely centralized place to put math based functions (myRate = baseRate+riskRate). I have also added a factory method that help explain how this Rate object is being made. From whole percents such as 78% or 22%. Because we have hidden the way we actually store the value, we could also add support for 22.2% by adding a new factory method and changing the internal storage with out changing any other part of the code base. Very cool.

Ok, so what about saving these value objects and now I need to bind them to the UI how do I get at that hidden variable? I have taken quite a few paths when trying to implement this and the way that I do things now is a combination interface + base class. If you are anything like me you are thinking 'base class, yuck' and well I still do but this is the best way that I have come up with and I am open for suggestions. :)

So my 'business primitives' inherit from an abstract class called 'Primitive<T>' this class helps to streamline the creation of my business primitives. It also EXPLICITLY implements an interface called ValueObject<T> that exposes the underlying value, that can be used by UI controls and persistance frameworks with out mucking up my public API. I love that I don't see 'SetValue' and 'GetValue' unless I want to (yes, this could have been a property, not sure why I choose this). Here is the interface:

public interface ValueObject<T>
{
    void SetValue(T input);
    T GetValue();
}

and the base class

[DebuggerDisploy("{_primitiveValue}")]
public class Primitive<T> :
    ValueObject<T>
{
    T _primitiveValue;

    public Primitive()
    {
    }

    public Primitive(V primitiveValue)
    {
        _primitiveValue = primitiveValue;
    }

    void ValueObject<T>.SetValue(T input)
    {
       _primitiveValue = input;
    }

    T ValueObject.GetValue()
    {
        return _primitiveValue;
    }
        
    //equality stuff
}

I really wanted to do some tricky generics to try and implement the operator overloads in the base class as well, but the compiler wasn't to happy about that so those still have to be implemented in the 'Rate' class. Now my 'Rate' object looks like this:

public class Rate :
    Primitive<int>
{
    private Rate() { }
    private Rate(int value) : base(value){}

    //factory methods
    public static Rate FromWholePercent(int rate) { new Rate(rate);}

    //operator overloads should be implemented here

    public bool Equals(Rate other)
    {
        if (ReferenceEquals(null, other)) return false;
        if (ReferenceEquals(this, other)) return true;
        return base.Equals(other);
    }
}

For saving these buggers? Well, using NHibernate we can persist this as an 'int' using an IUserType, which makes things very simple and still manages to keep NH out of our domain.
Some links on implementing IUserTypes

Otherwise, with the interface you now have the means to get access to the value, so customize for your needs!

Now that we have addressed the saving aspect, what's a good way to present these 'business primitives'? Because

inputLoanPrincipal.Text = loan.Principal.ToUiString();

sucks. I would suggest some extension methods on your UI controls that take Primitive<T> as the type and can then cast to the ValueObject and get access to the value. Or extending the UI binding much in the way FubuMVC has, seems like a really solid way to approach things too.

I hope this helps :)

-d

Getting StructureMap off SourceForge, Thoughts?

Jeremy D. Miller — Wed, 03 Feb 2010 22:29:00 GMT

The original discussion for this topic is here: http://groups.google.com/group/structuremap-users/browse_thread/thread/6d579f4e9b508c66

All,

I've never liked SourceForge and it's a PITA for me to use even though it's gotten better over the years. I'd like
to move StructureMap off SourceForge and more importantly, get a real
Wiki site up so that we have at least a fighting chance of keeping the
documentation up to date. On the other hand, I get a significant
number of patches from you guys (thanks for that) and I'd also like a
better way of handling those submissions -- and making it easier for
*you* to get involved.

Right now, Josh and I are thinking about moving StructureMap to GitHub
(you knew that was coming) and trying to use the Wiki support on
Github for now. Granted, Git is weird as hell for those of us used to
SVN, but GitHub has some huge advantages for OSS community
development. I'd *love* to start managing StructureMap patches
through GitHub "pull" requests (or whatever the correct lingo is).

Any thoughts? Volunteers? ;)

Jeremy

An introduction to iptables

karl — Wed, 03 Feb 2010 14:36:00 GMT

iptables is a linux application that allows you to configure the built-in linux firewall. There are abstraction layers built on top of it, including nice GUIs, but I recently had some very basic rules I wanted to implement, and figured I'd learn how to do it directly in iptables. It turned out to be easy to configure, and I thought I'd give a very basic introduction.

First though, I relied on the ubuntu documentation to get up and running (https://help.ubuntu.com/community/IptablesHowTo). I'll pretty much just regurgitate what's in there - I've said it before, stop believing that linux documentation is written only for people who already know linux. Also, depending on your setup, most of these commands might require elevation (sudo).

By default, iptables defines three rule chains: INPUT, FORWARD and OUTPUT. We'll only concern ourselves with INPUT - namely the chain used for incoming packets directed at this particular machine. At any point, you can list the rules by entering iptables -L. If listing the rules turns out to be really slow, try using iptables -L -n. The -n option means that the display will output IP addresses and ports in numeric format, without trying to do a DNS lookup. If the -n option makes it fast, then you're system likely has incorrect DNS settings (you can check out http://www.cyberciti.biz/tips/linux-how-to-setup-as-dns-client.html for help with that).

In my particular case, the server is has two network interfaces - a public facing one (on eth0) and a private one (on eth1). For my purposes, I want to remotely (eth0) access SSH from my static IP, and locally (eth1) access postgresql on port 5432.

To accomplish this we simply append two rules to the INPUT chain:

iptables -A INPUT -p tcp --dport ssh -s 205.38.19.199 -i eth0 -j ACCEPT
iptables -A INPUT -p tcp --dport 5432 -i eth1 -j ACCEPT

The first rule appends itself to the INPUT chain. Its limited to the TCP protocol targeting the SSH port (22) with a source originating from 205.38.19.199 on the eth0 network interface. It jumps to an ACCEPT status (all other processing stops). The next rule is similar, except it allows any source so long as they are connected to eth0 and targeting port 5432 (over tcp).

We can now add a third rule to block all other access:

iptables -A INPUT -j DROP

if incoming traffic doesn't mean the first two criteria, we'll hit this third rule and the firewall will reject the connection.

We'll run into 1 issue with our above configuration though - we've blocked access to the loopback interface (127.0.0.1). We need to add a special rule to allow loopback connections (since a lot of programs rely on it). However, we can't simply append it as it'll never be reached. Instead of using -a to append, we'll use -i to insert:

iptables -I INPUT 1 -i lo -j ACCEPT

Here we are inserting our rule in the 1st position, and accepting all connections made on the special lo (loopback) interface.

A really neat thing about iptables is that they aren't persisted by default. So, if you happen to mess up and cut yourself off from your server, a simple reboot will reset everything (hopefully you have access to do a remote reboot from a web interface, or maybe you can just walk up to the machine and reboot it).

At some point though, you'll want to make sure your rules are persisted. Achieving this is a two step process. First, you save your rules to a file by using the iptables-save and redirecting STDOUT to a file:

iptables-save > /etc/iptables.rules

Second, and this depends on which distro you have but on debian/ubuntu, you make sure your rules are loaded on startup. Simply edit /etc/network/interfaces, find your interface, and add:

pre-up iptables-restore < /etc/iptables.rules

to the list, so that it looks something like:

auto eth0
iface eth0 inet static
address xxx
netmask yyy
gateway ddd
pre-up iptables-restore < /etc/iptables.rules

That's it!

Life outside .NET, or “How to check out your neighbours”

Kyle Baley — Wed, 03 Feb 2010 02:34:19 GMT

The hillbilly be all Java’d up these days. For coming on three weeks, I’ve been the lone developer on a project based on Google Web Toolkit. It’s a web framework (naturally) that allows developers to build applications in Java and compiles it down to JavaScript, CSS, and HTML. Scoff all you want, if it were any other company behind it, I’d probably be right there with you.

We considered quite a few technologies before landing on this one. We went through Ruby, Sharp Architecture, Open Rasta, Moo Tools, and probably several others. I can defend ending up Google Web Toolkit privately if you want but putting the thought process up in a public forum is going to lead to comments that I’m too tired to moderate these days. And yes, I’ve heard of Script #, too.

Coming at this from a .NET developer’s standpoint has been interesting. It’s surprising how much we take for granted in our IDE, for example. I’m still meandering my way through the keyboard shortcuts in Eclipse (after a brief fling with IntelliJ IDEA). One thing I’d really like is a keyboard shortcut for the GWT Compile button, which currently is available only via a toolbar button or a context menu, as far as I can tell. Was happy to find a VIM plugin for it too that works as advertised.

Not sure if this applies to Java in general but within the confines of the Google Web Toolkit, the ecosystem is freakin’ phenomenal. The documentation page alone encourages unit testing and the use of an MVP architecture. Once you start reading about it, you can’t help but stumble on a number of other projects:

gwt-presenter: A passive view implementation for GWT
gwt-dispatch: A command pattern implementation for GWT
Guice: Google’s dependency injection framework
Gin: A dependency injection framework for the client part of GWT

The shocking thing from a .NET perspective is that these concepts are just sort of assumed. There’s little debate on whether dependency injection is necessary or whether passive view is overkill. Someone watched a presentation from Google IO last year, whipped up a command pattern project based on it, and lo! the people said it was good. Between support for Hibernate and the App Engine data store, I think people would look at you bug-eyed if you even suggested writing your own data access layer.

The downside to all this as that the tooling seems to be several steps behind what I’m used to in the Microsoft world. It’s still too early to make a fair comparison but even after digging a little deeper into Eclipse, I can’t imagine being quite as productive as I currently am in Visual Studio. Yes, there’s also IntelliJ but our anecdotal evidence suggests that neither Java IDE is seen as a de facto standard. For the moment, I’m sticking with Eclipse simply because all the documentation refers to it and the GWT and App Engine plug-ins for it work out of the box.

Couple of final shout-outs to two blogs that have been invaluable during the learning curve phase. First is Hive Development (currently featuring two posts on how to unit test MVP applications in GWT). Second is TurboManage, whose sample code is more detailed than many apps I’ve written.

Anyway, it’s been an interesting couple of weeks.

Kyle the Decaffeinated

FubuMVC Learns to Speak Spark

Jeremy D. Miller — Tue, 02 Feb 2010 17:59:00 GMT

From Robert the Grey, FubuMVC learns to speak Spark.

I've done the nearly solo OSS thing a couple times to mixed results. I'm painfully aware that good OSS projects have a deeper community of contributors than just one guy, and that's why I'm so thrilled to see this addition come into the nascent FubuMVC reboot from outside the Dovetail office.

A Kick in the Monads – Writer Edition

Matthew.Podwysocki — Tue, 02 Feb 2010 04:59:02 GMT

In the past couple of Monads posts, we’ve talked briefly about the State and Reader Monads and their potential uses and misuses. Before this series completes, I have a few more to cover including the Writer, Continuation and eventually Observable monad. Today, we’ll get started looking at the Writer Monad and what it can do for us.

What’s the Motivation?

Before we dive deep into what the Writer Monad is, let’s go deeper into the motivation of why we might consider this approach. Like proper developers should when approaching a new concept, we should ask, “What problem are we trying to solve? What’s the motivation here?” else we end up with an over-applied solution to our problem. In this case, let’s take the simple example of logging or tracing in our application. Typically in logging scenarios, we could have the dreaded singleton logger.

let doSomething() =
  Logger.Instance.Log("Beginning doing something")
  
  // Doing something
  
  Logger.Instance.Log("End doing something")

Or perhaps, we could have an injected ILogger instance handed to us via a constructor for the purposes of logging.

type ILogger =
  abstract member Log : message : string -> unit

type DreadedManager(logger : ILogger) =

  member __.DoSomething() =
    logger.Log ("Start doing something")
    
    // Do something

    logger.Log("End doing something")

Or even in other scenarios, we might imagine putting in some AOP behavior for the purposes of logging, but that may of course not be fined grained enough what we need. Instead of doing this, how about generating some output “on the side” in a more functional manner. What if we could instead write something like the following where I add two numbers (simplistic example I know) and then run the computation?

let addNumbers x y = writer {
  do! logMsg (sprintf "Adding %d and %d" x y)
  return x + y };;
  
> val addNumbers : int -> int -> Writer<string list,int>

> addNumbers 3 4 |> runWriter;;
val it : int * string list = (7, ["Adding 3 and 4"])

What we’re seeing is that in my addNumbers function, I take two integer arguments and then log a message and finally return the computed value. What’s more interesting is the fact that we’re logging something physically alters the signature of our method to indicate such a thing is happening. When we compute our function, we not only get the result of 7 that we’re expecting, but also our transaction log as well. Then we can decide what we want to do with the log, for example persist it somewhere, clean it up, etc. So, how can we do this exactly?

Defining the Writer

So, now that we covered the motivations around what it is and why we might use it, let’s look at how we might implement it. In order to maintain both the transaction log and the return value of our method, we’ll need to create a container to hold these values. In this case, we have the Writer<’W,’T> where the ‘W is the writer, which in our case above was a simple string list, and the ‘T is the result of our method. We have a constructing function of our Writer which takes a function with no parameters and returns a tuple of our result and the log.

type Writer<'W,'T> = Writer of (unit -> 'T * 'W)

In addition, we’ll need a way to run our Writer so that we can return our tuple of our value and the log. Let’s create a function called runWriter which computes our Writer.

let runWriter<'W,'T> (Writer w) : ('T * 'W) = w()

Before we get started on the Monad part, there is another piece we need to understand, and that’s the Monoid.

Don’t Avoid the Monoid

Before everyone panics as I’ve brought up a work that sounds like Monad, just rest easy. In fact, it’s much easier to understand than the dreaded M word. A Monoid is an algebraic data structure with a simple associative binary operation and an identity element. Just to bring that into real-world speak, we could have a Monoid for natural numbers with an identity element of 0 and the associative binary operator of addition, or in the case of lists, we could have the identity element of an empty list and an associative binary operator of append. In Haskell, such a thing is implemented through a type class, but since in F#, we don’t have this, let’s instead create a simple interface to encompass the same behavior.

type IMonoid<'T> =
  abstract member mempty  : unit -> 'T
  abstract member mappend : 'T * 'T -> 'T

In this instance, we have two methods we care about, defining our identity (mempty) and our binary operator (mappend). For example, we could implement a Monoid for a simple F# list such as the following:

type ListMonoid<'T>() =
  interface IMonoid<'T list> with
    member this.mempty() = []
    member this.mappend(a, b) = a @ b

This instance in particular will come in handy when we’re talking about a simple logging solution. Our mempty simply returns an empty list of our ‘T objects and our mappend appends the first list to the next. Now, what we need is some sort of registration process for our IMonoid instances so that we could pick one up based upon the incoming type. We could use something like a Common Service Locator to do this and it could be idea for a testing situation, but for now, lets just hand roll a global associations which maps an instance of our IMonoid to our proper type.

type MonoidAssociations private() = 
  
  static let associations = new Dictionary<Type, obj>()
  
  static member Add<'T>(monoid : IMonoid<'T>) = 
    associations.Add(typeof<'T>, monoid)
  
  static member Get<'T>() = 
    match associations.TryGetValue(typeof<'T>) with 
    | true, assoc -> assoc :?> IMonoid<'T>
    | false, _    -> 
        failwithf "No IMonoid defined for %O" <| typeof<'T>

Once we have this defined, we could add instances to this associations class such as a string list implementation:

MonoidAssociations.Add(new ListMonoid<string>())

And now we can use the associations class to call instances of our IMonoid for our functions of mempty and mappend.

let mempty<'T> = MonoidAssociations.Get<'T>().mempty
let mappend<'T> a b = MonoidAssociations.Get<'T>().mappend(a, b)

After that little diversion, we’re now able to get back to the point of the post, the Writer itself. But outside of here, that’s probably the last time you’ll probably use the word Monoid. But, I’m sure now you could impress your friends with the use of said word.

Defining the Builder

As you may remember from the previous post, the monad must support three basic rules. First, a type construction, for each underlying type, we must be able to get the corresponding monadic type. Second, we must have a function that maps an underlying value to a value in the corresponding monadic type, which is called the return function. Third, we must have a binding operation where the first argument is a value in a monadic type, its second argument is a function that maps from the underlying type of the first argument to another monadic type, and its result is in that other monadic type.

Let’s first tackle the return function. From our previous creating a Builder posts, we should remember that the Return should have the following signature where we take a value of T and then return it’s Monadic type.

type Builder() =
  member Return : 'T -> Monad<'T>

Our implementation should take a value of a and construct a Writer with a function with no arguments and return a tuple of our value and an empty Monoid instance.

type WriterBuilder() =

  member this.Return<'W,'T>(a : 'T) : Writer<'W,'T> = 
    Writer(fun () -> a, mempty())

Next, we need to define the bind operation. The point of this method is so that we can bind two monadic types together such as two let! or do! statements. As you might recall, this method takes a Monadic type of ‘T and a function that takes a ‘T and returns a Monadic type of ‘U, and the return type of our bind should be the Monadic type of ‘U.

type Builder() =
  member Bind : computation : Monad<'T> *  
                binder : ('T -> Monad<'U>) -> Monad<'U>

Our implementation should look like the following which creates a Writer with a constructed function which takes no parameters and then calls runWriter on our first Writer m which returns a tuple of our result and a log. We then execute the binder function with our result a which then gives us our second result and a log. Finally, we return a tuple of our second result with our two logs appended to each other.

type WriterBuilder() =

  member this.Bind<'W,'T,'U>(
    computation: Writer<'W,'T>, 
    binder : 'T -> Writer<'W,'U>)  : Writer<'W,'U> =
    Writer(fun () ->
      let (res1, log1)  = runWriter computation
      let (res2, log2) = runWriter (binder res1)
      in  (res2, mappend<'W> log1 log2))

You can find the rest of the methods in order to create a fully functioned builder as a Gist on my GitHub. Now let’s talk about some helper methods. The first, and most useful method is the tell which adds an entry to our log. This function takes a log entry and creates a Writer with a function that takes no arguments and returns a tuple of unit (void for some folks) and our log entry.

let tell logEntry = Writer(fun () -> (), logEntry)

Next up is the listen function. This allows us to listen to our log output that is being generated by our writer. This function takes a Writer and executes it while returning a tuple of our result and a log, as well as a log.

let listen writer = 
  Writer(fun () -> let (result, log) = runWriter writer 
                   in ((result, log), log))

The last function we’ll cover is the censor function. This function returns a new Writer whose result is the same, but the alters the log based upon what is supplied as a parameter

let pass   m = 
  Writer(fun () -> let ((a, f), w) = runWriter m in (a, f w))
  
let censor censoredValue writer = 
  writer { let! result = writer
           return (result, censoredValue)
         } |> pass

Doing Something Useful With It

Ok, our helpers are now defined, so let’s go back and figure out how we’re going to log messages. If you remember from above, we have the tell function which does exactly that. Let’s implement that to take a message and call the tell function with our message wrapped in a list.

let logMsg (message : string) = tell [message]

Now we can try it out in such a function which does some file processing for us with some logging along the way.

let processFiles files = writer {
  try

    do! logMsg "Begin processing files"
    for file in files do
      do! logMsg (sprintf "Processing %s" file) 
      processFile file

    do! logMsg "End processing files" 

  with e -> 
    do! logMsg (sprintf "An exception occurred %s" (e.ToString())) }

At the end of this method, it should return to us a tuple of unit and our log entries that happened along the way such as this:

> processFiles files |> runWriter;;
val it : unit * string list =
  (null,
   ["Begin processing files"; "Processing C:\Test1.txt";
    "Processing C:\Test2.txt"; "End processing files"])

This of course is a pretty contrived and simple example, yet pretty interesting nonetheless. But, in an impure world that we live in with such languages as F#, C#, etc, how practical is it? That’s another matter altogether and good arguments on both sides. Using a writer implies some sort of change to your system to allow for logging, whereas in a more impure environment, logging could take place everywhere. So, when dealing with an impure world already, just go with what you know.

Conclusion

Once again, by looking at Monads, we can discover what abstractions can be accomplished with them, but just as well, what they are not about. Certainly, functional languages don’t need them, but they certainly can be quite useful. When we find repeated behavior, such as logging, this abstraction can be quite powerful. Practically though in languages such as F#, they can be useful, but other patterns and abstractions can as well. Find the right abstraction and use it.

Exporting dynamically changing configuration values

Glenn Block — Sun, 31 Jan 2010 21:45:49 GMT

In my last post I discussed how to export configuration. A follow up question in the comments was “What if the values change?” Meaning the values that are exported using the approach I illustrated are static. In the real world however values often can change based on some user setting etc. A variant of the approach however allows the values to not be static. Instead of exporting a value, export a Func which returns the value. MEF offers nice support for this through method exports. For example to allow the “recently used file” config item to change over time, we can modify the Exporter to export that value as a method rather than a property.

public class RecentlyUsedTrackerConfiguration
{
  private IConfigurationProvider _provider;
  [ImportingConstructor]
  public RecentlyUsedTrackerConfiguration(IConfigurationProvider provider)
  {
     _provider = provider;
     MaxItems = provider.GetValue<string>("recentlyUsedTracker.maxItems");
  }
  [Export("RecentlyUsedTracker.File")]
  public string GetFile() {
    return _provider.GetValue<string>("recentlyUsedTracker.maxItems");
  }
  [Export("RecentlyUsedTracker.MaxItems")]
  public int MaxItems {get;private set;}
}

Instead of exporting a property, we are now exporting the GetFile method. Method exports are imported as delegates, thus RecentlyUsedTracker now looks like this.

[Export]
public class RecentlyUsedTracker {
  [Import("RecentlyUsedTracker.File")]
  public Func<string> File {get;set;}
  [Import("RecnetlyUsedTracker.MaxItems")]
  public int MaxItems {get;set;}
}

Notice above we are importing a Func<string> for the File item rather than string. This gives us the hook to dynamically change File each time it is accessed. You could even go further an parameterized File if you wanted to pass in context to determine which File is returned.

It’s still easy to test

With this approach RecentlyUsedTracker is still easy to test. With lambda syntax it is pretty painless to pass in test values when the class is under test.

From Hyper-V back (?) to Virtual PC

pvanooijen — Sun, 31 Jan 2010 13:56:00 GMT

For over a year I have been using Server 2008, 64 bits, as OS for my laptop. The main reason for this platform was Hyper-V. Almost every other project I’ve been working on needs another virtual server. And each location I am working has a different network. With Hyper-V both switching servers and switching networks works fast and good. The downside of using Hyper –V is that it knocks out all possibilities of hibernating or putting my laptop to sleep. Server 2008 R2 boots a lot faster, but still. Another downside is that to use Hyper-V you have to run the 64 bit versions, R2 only comes 64 bits. Visual studio is a 32 bit app, runs OK on 64 bits but it is still not the most stable piece of software I know.

Due to circumstances I had to use my laptop more and more in typical mobile situations. Also the way my colleague presses the power button, is back where he was, does his thing, closes the lid and just walks away made me a little jealous. Perhaps I should move on to Windows 7 and try Virtual PC 2009. I had played with that combination and it looked promising.

To see if this was a good idea I set up some some tests

Is it possible to migrate the hyper-V virtual machines to Windows 7 virtual PC ?
Can you switch networks in a virtual machine without the need of a reboot ?
How does a running virtual machine survive a sleeping machine ?
How does a running virtual machine survive hibernation ?

All version of hyper-V and virtual PC share the same virtual hard disk (vhd) format. They differ on the integration features, some piece of host specific software installed on the virtual machine to facilitate all communication with virtual machine. Both Hyper-V and Virtual PC have “Install integration features” as menu option.

As a test candidate I took a virtual machine with quite a history. It started its life in Virtual PC 200x as a Windows server 2003 machine with several monsters of sql 8 databases, sql reporting services and some COM custom app. Over the years it had been upgraded tot server 2008 and been living under several versions of Virtual server and Hyper –V. Not something to rebuild from scratch, just getting that version of reporting service to work is a piece of science on itself. In short: a typical real world machine. Under the several host OS-es it had seen several completely different versions of integration services. These were pretty screwed up. Every attempt to install the newest integration services resulted in messages complaining about previous versions. But the machine still worked.

Migrating

The official recipe to migrate a virtual machine is to uninstall integration services, move the machine and reinstall the integration services of the new host. But you will not find integration services under the installed programs. All attempts to uninstall form the command prompt (/Uninstall) only resulted in the same messages about previous versions.

What worked is changing the HAL (Hardware Abstraction Layer) of the virtual machine:

Start MSconfig
Boot Tab
Advanced Options
Check the “detect HAL” box

After that I just shut down the machine, copied the hard disk and created a new virtual machine in W7 Virtual PC using the copied vhd file as hard disk.

The machine booted and complained about requiring new drivers. It also required renewed activation. I installed the W7 Virtual PC integration services and allowed the renewed activation (which is never a problem with MSDN OS licenses). And after that the machine just worked fine. All integration was smooth, all software had perfectly survived the migration.

Switching networks

I can be short on this. This works just as smooth as in Hyper-V

Changing the adapter in the settings is instantaneously reflected in the status of the virtual machines adapter. The good thing is that everything works just as well with an adapter with a dynamic IP address as with one with a static address.

Sleep and Hibernate

The difference between sleep and hibernate is that in sleep mode the RAM of the PC is still powered, so actually the machine is still alive. In hibernate mode all RAM is saved to and restored from disk.

In Hyper-V the virtual machines are running on the machine level. In virtual PC you start a virtual machine as a logged in user. When logging off the virtual machines are shut down (or hibernated). Instead of logging of I tried both sleep and hibernate with the virtual machine still running. Again all news is good. All functionality completely survives both scenarios. Virtual PC is not ignorant of my actions. When hibernating it will (automatically) disable the integration services. When awakening it restores them.

To conclude

The only hurdle I had to take was the HAL setting when migrating the machine. All the rest just worked. So I repaved my laptop with Windows 7 and virtual PC 2009. (Just skip the virtual XP step unless you need a virtual XP machine). I was quite satisfied with Server 2008 (except the required full boot) but do like Windows 7 even better. VS worked well and now even works better. But that could be the result of a fresh install (there is no upgrade possible from 2008 to 7).

And now I can also close the lid of my laptop and leave the building.

Dovetail is Hiring

Jeremy D. Miller — Fri, 29 Jan 2010 21:17:00 GMT

This is a different project than the one we hired for last time. If you've spoken to us before, please consider this position separately.

We're expanding the development team on our line of existing products. You'll be working on a small team that develops applications for large businesses using some of the latest technology. You will be involved in all aspects of solution development, including analysis, design, development, testing, documentation, and support.

We’re looking for a software developer with demonstrable C# (preferably .NET 2.0 or later) and HTML/CSS experience (ASP.NET MVC is a plus). Any experience with test-driven development or automated unit testing in general is a huge plus. Also, participation in the community (attendance of events, avid blog reader + commenter, or maybe you even have a blog yourself) will put you firmly in the running for this position. We’re looking for people that believe learning and continuous improvement are primary responsibilities of a software developer. We’re hiring motivated people for a terrific opportunity with a team of recognized .NET and agile community leaders.

Our practices and technologies include:

Test-driven development
Continuous integration
Behavior-driven design
Domain-driven design
HTML, CSS, Javascript (jQuery)
ASP .NET MVC
C# 3.0, .NET 3.5, Visual Studio 2008
SQL 2008
Oracle
NHibernate 2.x
StructureMap

Email us and tell us why you’d make a great addition to our team: tech-jobs@dovetailsoftware.com

This is a full-time, on-site position in our Austin, TX office. Please DO NOT contact us for outsourcing or tele-commuting.

Shrink your Views with FubuMVC Html Conventions

Jeremy D. Miller — Fri, 29 Jan 2010 17:00:00 GMT

Yesterday I was able to “push” into Github the work I’ve been doing for convention based Html generation in FubuMVC. What the hell is “convention based Html generation?” you ask? It’s simple in concept. Your team has policies, formal or informal, for how you build Html elements for the fields in a ViewModel. If your familiar with MvcContrib’s Opinionated Input Builders or MVC2’s Templates feature (very well described by Brad Wilson here), we’re doing the same thing conceptually but with much different mechanics. Right now, I’m focused on the very basic building block methods that appear on FubuMVC view’s (remember that we basically force all views in FubuMVC to be strongly typed with a single ViewModel):

InputFor( expression ) – write an Html element to edit a single property on the ViewModel. Instead of calling TextboxFor(x => x.Something) or DropdownListFor(x => x.Other) we can just say InputFor(x => x.Some.Property.On.The.ViewModel) and let the conventions figure out what to do from there. If we need to change the model property to something else, or change our conventions about how elements should be constructed, no big deal.
DisplayFor( expression ) – write an Html element to display the value of a single property value on the ViewModel. String fields are just displayed. Entity fields may be displayed as a link to more information on that link. Date fields are shown in short date format, etc.
LabelFor( expression ) – write an Html “label” element for the field. Out of the box, FubuMVC will just put in the field name, but that’s not all that useful. In our Dovetail project we have this tied into our localization subsystem to pluck out a localized header text for the desired property.

I’m dubious that the form auto-generation stuff that MVC2 does has much real world value, but it would certainly be possible to build on top of what we already have. In a follow up post I'll show more of the DSL-ey approach for creating simple forms that uses InputFor/DisplayFor/LabelFor as building blocks.

Example

In our system we have a small Entity class named Address (all systems of any complexity have an “Address” class, but they’re all different) with a property for the first line of the address called Address1:

        [Required, MaximumStringLength(250)]
        public string Address1 { get; set; }

Leaving the appropriateness of the approach aside (it’s working very well), we use attributes for our simple validation rules (and also use those to generate “not null” / string length types of rules in our database). On the client side, we use jQuery Validation to do input validation in the browser. jQuery Validation is very simple to use (as long as you color within the lines). All I need to do is add classes and some attributes to the <input> and <select> elements to declaratively apply validation rules.

In usage, we could build the input Html element for a field by just calling InputFor() like this:

    <dd><%= this.InputFor(m => m.Site.PrimaryAddress.Address1).Id("site-address1")%></dd>

In our Dovetail system the above call generates this Html:

    <input id="site-address1" class="required" type="text" 
        name="SitePrimaryAddressAddress1" label="Address 1" maxlength="250" value=""/>

Did you see what happened there? When we create an input element for the Address.Address1, the conventions:

Built a textbox element. If the property was a boolean, the conventions would build a checkbox instead. Likewise, if the property is a DateTime or DateTime? field the conventions would build a date picker.
Set a “name” attribute” that matches our naming convention so that model binding works smoothly from client to server and in automated testing scenarios. In our case we just take the “path” to a property from the ViewModel and tear out the “.” characters
Adds the "label” attribute with the localized header name for this field. This is used in conjunction with the jQuery validation to present a clean, localized validation summary on the screen
Recognizes the presence of the [MaximumStringLength] attribute and sets the “maxlength” attribute
Puts the property value into the “value” attribute. The example I used happens to come from a “New” screen, so the value is blank
Recognizes the presence of the [Required] attribute and adds the “required” class to the element

By the way, did you see how I overrode the “id” property of that textbox? I’ll talk more about that at the bottom, but that represents a huge advantage that FubuMVC’s model has over both MvcContrib and MVC2. You can happily modify or enhance the convention-generated Html input on a case by case basis.

Can I make my own Conventions?

One of the overarching principles of FubuMVC is to push the usage of Convention over Configuration as far as it can go while still allowing FubuMVC adopters to create and add their own conventions. The Html conventions are no different. When you register / configure conventions for the Html you can register either “Builders” that know how to generate the HtmlTag (I’ll explain HtmlTags later) for a certain class of properties:

    public delegate HtmlTag TagBuilder(ElementRequest request);
 
    public interface IElementBuilder
    {
        TagBuilder CreateInitial(AccessorDef accessorDef);
    }

or “Modifiers” that enrich HtmlTag’s:

    public delegate void TagModifier(ElementRequest request, HtmlTag tag);
 
    public interface IElementModifier
    {
        TagModifier CreateModifier(AccessorDef accessorDef);
    }

These ElementBuilder’s and ElementModifier’s can either be classes that you build yourself and “plug” in, or you can use the Html convention DSL shown below to create common, simple types of policies (think, if this attribute exists, add this class). A custom ElementBuilder might look like this:

    // This builder is only for creating the display tag
    // for a date time field on one of our "activity log"
    // models
    public class LogDateDisplay : ElementBuilder
    {
        // Does this builder apply to a property?
        protected override bool matches(AccessorDef def)
        {
            return def.ModelType.Closes(typeof (LogViewModel<>)) && def.Accessor.PropertyType.IsDateTime();
        }
 
        // Renders a date in long time format and also sticks the header
        // text into the title attribute
        public override HtmlTag Build(ElementRequest request)
        {
            string title = LocalizationManager.GetHeader(request.Accessor.InnerProperty);
            return new HtmlTag("span").Text(request.ToDisplay("{0:F}")).Title(title);
        }
    }

Alrighty, let’s move on to registering our conventions. From the top, I create a class to hold my project’s Html conventions like so:

    // HtmlConventionRegistry is the base class that provides the DSL
    // This is an example of "Object Scoping" from Fowler speak like
    // StructureMap's Registry and Fluent NHibernate's ClassMap
    public class DovetailHtmlConventions : HtmlConventionRegistry
    {
        public DovetailHtmlConventions()
        {
            validationAttributes();
            numbers();
 
            Profile("edit", x => x.Editors.Builder<EditInPlaceBuilder>());
 
            editors();
 
            Labels.Builder<LabelBuilder>();
 
            Displays.Builder<LogDateDisplay>();
            Displays.Builder<DisplayBuilder>();
 
        }
 
        private void editors()
        {
            Editors.Builder<ValueObjectDropdownBuilder>();
            Editors.IfPropertyIs<bool>().BuildBy(request => new CheckboxTag(request.Value<bool>()).Style("width", "auto !important").Attr("value", request.ElementId));
 
            Editors.Always.Modify((request, tag) =>
            {
                tag.Attr("label", request.Header());
                tag.Attr("name", request.ElementId);
            });
 
            // Ugly hack because of the hacky Edit in Place jQuery plugin we use, but
            // I'm gonna kill it some day
            Editors.IfPropertyTypeIs(t => t.IsDateTime()).Modify(x =>
            {
                if (!x.HasMetaData(EditInPlaceBuilder.EDITABLE_ATTRIBUTE_NAME))
                {
                    x.AddClass("DatePicker");
                }
            });
        }
 
        // Setting up rules for tagging elements with jQuery validation
        // metadata
        // I think that a lot of this gets added into the core Fubu as a
        // "jQueryValidationPack"
        private void numbers()
        {
            Editors.IfPropertyIs<Int32>().Attr("max", Int32.MaxValue);
            Editors.IfPropertyIs<Int16>().Attr("max", Int16.MaxValue);
            Editors.IfPropertyIs<Int64>().Attr("max", Int64.MaxValue);
            Editors.IfPropertyTypeIs(t => t.IsIntegerBased()).AddClass("integer");
            Editors.IfPropertyTypeIs(t => t.IsFloatingPoint()).AddClass("number");
        }
 
        // Declare policies for using validation attributes
        private void validationAttributes()
        {
            Editors.AddClassForAttribute<RequiredAttribute>("required");
            Editors.ModifyForAttribute<MaximumStringLengthAttribute>((tag, att) =>
            {
                if (att.Length < Entity.UnboundedStringLength)
                {
                    tag.Attr("maxlength", att.Length);
                }
            });
 
 
            Editors.ModifyForAttribute<GreaterOrEqualToZeroAttribute>(tag => tag.Attr("min", 0));
            Editors.ModifyForAttribute<GreaterThanZeroAttribute>(tag => tag.Attr("min", 1));
        }
    }

HtmlTags

The basis for FubuMVC’s Html conventions, and the big differentiating feature from the MVC2 and MvcContrib approach, is the usage of the “HtmlTags” library as a semantic model. All the Html generation in FubuMVC works by building up HtmlTag objects that represent an Html element graph (HtmlTag’s can have children). Think of the old TagBuilder class on steroids. A picture’s worth a thousand words, so let’s see some samples of HtmlTag in action:

            // Setting the inner text and adding a class
            HtmlTag tag = new HtmlTag("div").Text("my text").AddClass("collapsible");

            // adding "MetaData" for the jQuery MetaData plugin
            HtmlTag tag = new HtmlTag("div").Text("text");
            tag.MetaData("a", 1);
            tag.MetaData("b", "b-value");

        [Test]
        public void render_multiple_levels_of_nesting_2()
        {
            HtmlTag tag = new HtmlTag("html").Modify(x =>
            {
                x.Add("head", head =>
                {
                    head.Add("title").Text("The title");
                    head.Add("style").Text("the style");
                });
 
                x.Add("body/div").Text("inner text of div");
            });
 
            tag.ToCompacted().ShouldEqual(
                "<html><head><title>The title</title><style>the style</style></head><body><div>inner text of div</div></body></html>");
        }

The HtmlTag model has been hugely advantageous because:

It greatly simplifies Html construction. No ugly string bashing, class and attribute merging is handled internally by HtmlTag itself, and we’ve got plenty of convenience shortcuts. Compare this model to using user controls with tag soup or brute force string manipulation
Allows us to create an incremental model of “policies” to add classes and attributes to elements rather than having to make one big blob of code to create the Html (something that plagues both the MvcContrib and MVC2 designs)
The InputFor(), DisplayFor(), and LabelFor() methods all return the HtmlTag object created by the convention, and HtmlTag itself has fluent builders so that you can override or extend the Html created by the conventions on a case by case basis. We’ve gotten some great feedback and help with this feature from the MvcContrib guys, and this is their main complaint with using User Controls.
The conventional Html generation is pretty testable in basic xUnit tests without ever having to mess with WatiN or Selenium. That’s a huge plus in my book

HtmlTags is a separate library within FubuMVC that can be used independently (I use it in StoryTeller now).

Select Box Example

I’ve had this feature, and even the technical direction, in mind since last summer. I finally got to build it out for Dovetail usage because we needed to change the way we do configurable lists in our system. We keep list data in a database table where it’s easily editable and extensible (even to the point of adding cascading relationships after the fact for customizations). We need to validate certain fields against that list data, so we mark those fields like this:

        // There is no logic associated with Origin
        // other than externalized rules, so having it
        // be a string does no harm
        [Required, ValueOf(ListNames.Origin)]
        public string Origin { get; set; }

Anytime a property is decorated with the [ValueOf] attribute we know that we need to build a dropdown list to edit that field. All the information that we absolutely need to know to construct that dropdown is available on the property itself, so it made perfect sense to move to convention based Html construction instead of all the repetitive “put list data on ViewModel in Controller, transmit to View, fill options in View code” work we were doing before. We cache the list data in a static class called ValueObjectRegistry that can give us list data. Using ValueObjectRegistry and the Html Conventions gave us this:

    // Builds a <select> tag and fills in the list values 
    // for any property in our system that is "marked" as being
    // a list field
    public class ValueObjectDropdownBuilder : ElementBuilder
    {
        protected override bool matches(AccessorDef def)
        {
            return def.Accessor.HasAttribute<ValueOfAttribute>();
        }
 
        public override HtmlTag Build(ElementRequest request)
        {
            string defaultValue = request.Value<string>();
 
            if (defaultValue.IsEmpty())
            {
                request.ForListName(name =>
                {
                    ValueObject @default = ValueObjectRegistry.FindDefault(name);
                    if (@default != null) defaultValue = @default.Key;
                });
            }
 
            return new SelectTag(tag =>
            {
                request.EachValueObject(vo => tag.Option(vo.LocalizedText(), vo.Key));
                tag.SelectByValue(defaultValue);
            });
        }
 
        public static HtmlTag Build(string listName)
        {
            return new SelectTag(tag =>
            {
                ValueObjectRegistry.GetAllActive(listName).Each(x =>
                {
                    tag.Option(x.LocalizedText(), x.Key);
                });
 
                var defaultVO = ValueObjectRegistry.FindDefault(listName);
                if (defaultVO != null)
                {
                    tag.SelectByValue(defaultVO.Key);
                }
            });
        }
    }

Now that we have ValueObjectDropdownBuilder hooked into our Html conventions, all I need to do on the view is just say: “InputFor(x => x.Case.Origin)” and let the conventions handle everything.

Any questions?

Open Rasta presentation, or “How to throw a rest into the mix”

Kyle Baley — Thu, 28 Jan 2010 16:56:08 GMT

I’m imagining the thought process of some of the session voters for the upcoming Mix conference. “Hey, here’s one on Open Rasta by the Coding Hillbilly. You know what would be funny? Let’s all vote for it even though he just submitted it on a lark to get some practice after taking time out from speaking engagements. It’ll be fun watching him explain to Mrs. Billy that he *has* to go to Vegas four weeks before he’s heading to Philadelphia for Udi Dahan’s course.”

Yeah, you’re all a bunch o’ comedians, ain’t ya. Well, I’ll show you. You’ll go to my Open Rasta session ready to watch me squirm and you’ll see no such thing. I don’t want to overhype it or anything but I can tell you without a doubt that this session is going to restore your virginity and then take it from you again. Savagely (but tastefully; last thing I need is a bunch of people accusing me of statutory rape in the middle of a presentation). Then maybe next time you’ll think twice before crossing a coder of the earth, woncha!

Couple of interesting tidbits on the session:

Somewhere along the line, the original title got changed. I submitted it with: “Open Rasta: The REST framework MVC wants to be.”
I also submitted a session on S#arp Architecture. (What can I say? I’m a web framework kinda guy.) I found it interesting that the Open Rasta one got chosen and the #arch one didn’t.

So while you’re waiting for Mix, have a gander at Open Rasta to see what all the hubbub is about. Between this and my new contract using Google Web Toolkit, that should set the stage for my post activity for the next few months.

Kyle the Bastardized

Beyond web.config

karl — Thu, 28 Jan 2010 14:43:00 GMT

I recently needed a configuration mechanism which would detect changes without requiring an application domain restart. I also wanted to move away from XML. This is what I came up with (and hopefully I'll get some helpful feedback).

First, we declare a ConfigurationData object which holds our actual configuration values:

public interface IConfigurationData
{
   bool LogAll{ get; }
   string CdnUrl{ get; }
}

public class ConfigurationData : IConfigurationData
{
   private bool _logAll;
   private int _cdnUrl;
   
   public bool LogAll
   {
      get { return _logAll; }
      set{ _logAll = value; }
   }
   public string CdnUrl
   {
      get { return _cdnUrl; }
      set { _cdnUrl = value; }
   }
}

There isn't much to explain here, so let's move on to the class that does the heavy lifting:

public static class Configuration
{
   private static readonly string _applicationPath = HttpRuntime.AppDomainAppPath;
   private static ConfigurationData _instance = LoadInitialConfiguration();

   public static IConfigurationData GetInstance
   {
      get { return _instance; }
   }

   private static ConfigurationData LoadInitialConfiguration()
   {
      var watcher = new FileSystemWatcher(_applicationPath, "settings.config");
      watcher.NotifyFilter = NotifyFilters.LastWrite;
      watcher.Changed += (s, e) => _instance = LoadConfiguration();
      watcher.EnableRaisingEvents = true;
      return LoadConfiguration();
   }
   private static ConfigurationData LoadConfiguration()
   {
      return Converter.DeserializeFromFile<ConfigurationData>(_applicationPath + "settings.config", "_");
   }        
}

The class essentially loads the ~settings.config file, and sets up a watch to reload it whenever it changes. Here I'm using JSON (and my own JSON library) to read the file, but you could use anything, such as yaml or xml. The file might look something like:

{
   "logAll": true,
   "_cdnUrl": "http://cdn.mysite.com/"
}

If you are using a DI framework, such as ninject, you can hook it via:

Bind<IConfigurationData>().ToMethod(c => Configuration.GetInstance);

otherwise, you can call it directly from code with:

if (Configuration.GetInstance.LogAll) {...}

There are two things you'll need to be careful with. First you'll want to make sure to avoid caching values within a class. For example, if you did something like:

public static class HtmlExtensions
{
   private static readonly string _cdnUrl = Configuration.GetInstance.CdnUrl;
}

then a copy of CdnUrl would be stored in _cdnUrl and changes to your file wouldn't be available to this class.

Secondly, the Changed event is known to fire twice. This shouldn't cause any threading issues, but if your LoadConfiguration is particularly intensive, or if you happen to be debugging something, then you'll at least know to expect it.

NDepend v3 is now 100% integrated in Visual Studio.

Patrick Smacchia — Thu, 28 Jan 2010 09:21:00 GMT

First of all, if you are like me, you certainly don’t want another Visual Studio extension that will slow down your work environment. So let’s be clear: tremendous efforts have been put on performance and memory consumption. Even on large code base, made of hundreds of thousands of lines of code and dozens of VS projects, Visual Studio is not noticeably slow down by the NDepend v3 addin. Check by yourself and try NDepend v3.0.0 Beta3 here (v3 Beta3 pro works with v2 pro licenses and a v3 trial version is also available). VisualStudio 2010, 2008 and 2005 are supported. VS 2010 Beta2 is not supported, NDepend v3 Beta3 works on the limited VS 2010 SLCTP3 and hopefully it will work with VS 2010 RC1 (to be released in a few weeks in February).

So what does NDepend v3 brings to the table? Simply put, what NDepend v2 does in the Continuous Integration/Build process, NDepend v3 does it live at development-time inside Visual Studio (of course CI/Build integration facilities are still supported). A progress circle, in the status bar of Visual Studio, constantly informs the developer if the code currently violates some CQL rules. An informative window appear when the circle is hovered by the mouse.

If you are serious about conventions in your code base, you can easily define your own CQL rules and make sure that they are checked automatically and often, even before developers commit their changes. CQL rules cover a wide range of concerns, including: structuring ; layering ; components boundaries ; code changes ; dozens of quality metrics ; code element naming ; NET Fx usage ; API usage ; API evolution and ascendant compatibility ; coverage ratio by tests ; dead-code detection ; un-optimal encapsulation, ; side-effects and mutability etc …(all this is detailed here).

It takes 2 to 5 seconds to check hundreds of CQL rules asynchronously on a low-priority thread in VS, at each compilation, or if your prefer every N hours (this is easily configurable). The magic behind this performance achievement comes from what we call incremental analysis: NDepend v3 only focuses on code that has been changed since the last analysis.

There are many other innovative capabilities brought by this new version of NDepend, let’s briefly mention some of them:

Multi VS solutions wide-analysis and collaboration: A NDepend project can spawn dozens of VS projects partitioned in several VS solutions. A same NDepend project can be attached to several VS solutions that represent your entire code base (eventually including tests projects). Once there are several solutions opened in several instance of VS (one for tests, one for UI code, etc.), NDepend menus lets you jump naturally from one solution to another; Concretely you can go to the source code definition of code element B defined in VS solution B from anywhere it is referenced in VS solution A opened in another instance of VS. A unique possibility and a huge time saver!

Rich Code Search in VS: All search capabilities of NDepend are now integrated in VS. VS itself and many other Addins comes with their own Search facilities. What makes NDepend search different is

NDepend search updates result instantly while refining search criteria, no matter how big is the code base nor the number of matches found,
NDepend search can be done according to plenty of different criteria (by text(s) in name, by regex(s) , by code metrics, by changes, by visibility, by purity…),
NDepend search by name comes with many unique facilities to make code search more efficient (more on this here Efficiently Searching Code Elements by Name),
Searching in diff between 2 versions of the code base is a unique way to code review changes (more on this here Drastically leverage your Code Reviews).
Search scope can spawn several VS solutions, includes tier code matched by search as well, and constitutes a point of jump across multi VS solutions opened in several VS instances..

Multi CQL Query Edition in VS: CQL is to a code base what SQL is to a relational database. Interestingly enough, the "Search in code" feature described above is just a CQL Query generator. You can edit several CQL Queries at a time in VS to query the code at whim or readily define new CQL rules, pretty much the same way you would write SQL code to query a relational database.

Code visualization in VS: Dependency Matrix, Dependency Graph and Metric View (treemap) are all available in VS, and you can jump to and from source code readily. All these panels come with new asynchronous and abortable computation facilities that you will likely never notice, since most of the time the panel layout is computed in a fraction of second.

Continuous comparison with a base line in VS: For a long time, NDepend v2.x lets users explore changes between 2 snapshots of a code base. With NDepend v3, we harness this feature to continuously provide in VS the information of what has been refactored or added since a particular base line. We expect that the base line will often be the most recently released in production version of the code. If you cared to save on your HardDrive a copy of the source code base line, NDepend will let you compare in a click from VS changes made in source files themselves.

Reflector disassembly’s comparison: NDepend can command Reflector from VS to disassemble in source file (in C#, VB.NET, IL etc.) any class or any method. With this facility, one click is enough to disassemble 2 versions of the same code element from 2 versions of the container assembly. Then, NDepend automatically opens the 2 disassembled code text files built with your favorite text comparison tool. This is ideal if you want to quickly check from production assemblies which recent changes might have caused a particular bug.

Deep VS Integration: Whether it is from Solution Explorer or Code Editor, all NDepend features are available on right-click as soon as the context can be recognized as a code element (including application or referenced assembly, namespace, type, method or field). All NDepend features (CQL query generation, interaction with code visualization panels, interaction with Reflector...) are grouped under a single NDepend menu. If you become addict, any NDepend menu can optionally be shown at the right-click menu first level.

NDepend Session state preserved: Now NDepend's panels states (and their undo/redo states as well) are persisted across VisualNDepend or VisualStudio sessions. When you open VS the day after, everything is in the same state as it was before you shut down your computer.

There are dozens of others cool features in the product including Rich informational contextual tooltip, Global summary of the code base, supports for .NET v4, Silverlight 3 and Reflector 6, dozens of UI usability enhancements (including some new facilities in the visualization with the Dependency Graph) etc … The vast majority of these evolutions has been driven from users feedback.

NDepend v3 is now in beta phase and we will have a final version in February. It is a Go Live beta, we are confident that the current NDepend v3 beta3 is stable and won’t disturb you in your work. All NDepend licenses sold from now are v3 compatible and questions concerning v2 licenses upgrading will be answered on-time on the web-site. Now download NDepend v3 and harness your VisualStudio work environment!

How do I expose configuration information through MEF?

Glenn Block — Wed, 27 Jan 2010 19:01:00 GMT

This question which recently popped on our forums is one of the common questions we hear from customers. In this particular case, wcoenen (the person in the forums) had recently used information that he wanted to pull from configuration and pipe to a part. He solved the problem by creating a special configuration provider service which he injected into the part to provide the config. The code for the consumer looked like this:

[ImportingConstructor]

public RecentlyUsedTracker(IConfigurationProvider configurationProvider)

{   

  this.recentlyUsedFile = configurationFile.GetValue<string>("recentlyUsedTracker.File");   

  this.maxItems = configurationProvider.GetValue<int>("recentlyUsedTracker.maxItems");

}

As you can see above RecentlyUsedTracker takes an import of configuration provider. The solution above does work. The biggest issue wcoenen raised is that coupling of the part to the config provider makes testing more difficult. It requires a mock service to be passed in to every test. Another subtlety is that you won’t know if the data is actually present until the code executes.

An alternative approach, use property exports.

A different way to approach this problem is to actually export the individual configuration values. We can still use the generic configuration provider, but we can keep a nice separation of concerns. The part can then import these values like any other import. MEF provides a very powerful facility for doing this called property exports. A property export is a property which is decorated with an export attribute. It is special because it provides a place for you to execute custom logic for retrieving a value and returning it to MEF, i.e. a custom factory. This is a different model than the traditional class-level exports which MEF is responsible for the creation . So using a property export we can easily surface configuration information and we can use any method we choose to get the value including the provider. For example, take a look at the code below.

public class RecentlyUsedTrackerConfiguration

{

  private IConfigurationProvider _provider;


  [ImportingConstructor]

  public RecentlyUsedTrackerConfiguration(IConfigurationProvider provider)

  {

     _provider = provider;

     File = _provider.GetValue<string>("recentlyUsedTracker.file");

     MaxItems = provider.GetValue<string>("recentlyUsedTracker.maxItems");

  }


  [Export("RecentlyUsedTracker.File")]

  public string File {get;private set;}


  [Export("RecentlyUsedTracker.MaxItems")]

  public int MaxItems {get;private set;}

}

RecentlyUsedTrackerConfiguration IS a part as you can see it has an importing constructor which takes a provider. But instead of exporting itself, it exports it’s properties which use the provider to get the values. It then assigns a string contract to each export which correlates to the configuration item it is exporting.

Note: You can make this more compile safe, by using constants or creating custom export attributes

Now let’s take a look at our consumer.

[Export]

public class RecentlyUsedTracker {

  [Import("RecentlyUsedTracker.File")]

  public string File {get;set;}

 

  [Import("RecnetlyUsedTracker.MaxItems")]

  public int MaxItems {get;set;}

}

RecentlyUsedTracker imports File and MaxItems. It’s nice and clean (aside from the attributes :-) ). We can now easily test RecentlyUsedTracker, as he has no dependency on a provider. All he cares about is that the exports he needs are in the container.

An additional benefit the above approach introduces.

If you read my my or Nick’s blog’s, then you’ve heard us talk about Stable Composition and Rejection. Parts that don’t have there required dependencies are rejected. That means that RecentlyUsedTracker will be rejected unless the config items he needs are present. It’s consistent with the way the rest of MEF works it ensures consistency of the system. Of course if you want to allow the part to be created even though the data is not present, you can always set the AllowDefault property on Import = true.

What else can use this approach for?

Using property exports has a million and one uses. Any time you need to integrate legacy or non-MEF components to MEF, property exports are usually a sure win! For example, let’s say you have an existing third-party class which you use in your system which is sealed. You can create that class in a property export and surface it to MEF. It’s also a great way to surface singletons that you don’t want parts to depend on. What do I mean? Check the code below as an example.

public class ApplicationPart

{

  [Export]

  public Application App {

    get{ return Application.Current;

  }

}

Any questions?

Business Primitives (1/2)

drusellers — Wed, 27 Jan 2010 12:53:39 GMT

Understanding the business has been stated time and again as being an important part of the development process. In order for me to better support the business one of the 'little' things that I am finding greater and greater love for is the 'business primitive', a very small object, often containing only a single field, that completely encapsulates one small, well defined idea of the business. This is most often a specific type of data, like 'Money'.

This does a couple of things for me right off the bat. One, my methods can now ask for these 'business primitives' rather than a language primitive which means there is more meaning in my methods so that they need less documentation and that I am less likely to pass the wrong string into the wrong position on a multi-parameter method. Two, I tend to stop talking in 'developer-speak' and start talking in the language of the business. "Ahh, so an Instrument is identified by a CUSIP!"

This is also a very easy way to start experiencing the benefits of DDD's 'Ubiquitous Language', as you build up a collection of business primitives your ability to discuss the business problem with the business people in the terms of the business should improve. After all, your business partners don't think in terms of 'strings', 'integers', or 'booleans' rather they think of their business process in terms of 'real world things' like 'Loans', and 'Investments' and most complex things are built up of smaller objects like 'Money', 'InterestRate', and 'CUSIP' your company's concept of primitives.

As the use of business primitives grows, your understanding of the business should start to stabilize, and should gain some sense of consistency with the business. For instance, if you have a 'Money' class then you have a perfect location to deal with money rounding issues.

If you find that this would be hard to start doing, I find that it is easier with primitives that are defined outside of the business itself. For example at the bank there is a concept of a ‘CUSIP.’ This is a industrywide identifier used to identify financial securities. It has a set of rules about how it can be composed. (http://en.wikipedia.org/wiki/CUSIP). You are going to have to conform to these standards anyways you might as well put all the rules in one place.

If you are familiar with DDD then I also want to be clear that 'business primitives' are VALUE TYPES, like a string or an integer, their value is their identity. One instance of CUSIP 'CUSIP 912827XN7' is equal to (==) another instance of CUSIP 'CUSIP 912827XN7', which makes sense, their identity is their value. This is distinctly different than the DDD ENTITIES where they are not equal based on the their values, but by their ID, so 'Loan' with value $100 would not equal another loan that also has a value of $100.

In closing, why is 'primitive envy' (the overuse of programming language primitives in place of real objects) such a pervasive problem? I think that it has a lot to do with UI control binding. When we are building some of our first programs we need to send a string to the screen so we can see 'Hello World', we don't build out a 'Message' object and then send that to the screen through a ViewModel abstraction. But these behaviors that we build early in our careers can be a deep seated habit that is hard to break out of. Its just too easy to think about the UI and that its going to need a string for the name text box, and then code the 'name' as a string in your object. So push back, reclaim so OO love and work with your team to build some real business primitives.

My next post will show how we can implement this process.

MVC or WebForms: It's more about client side vs server side

Ian Cooper — Wed, 27 Jan 2010 03:34:00 GMT

Scott Guthrie has posted on the growing debate over Webforms vs. MVC, a debate that seems to be raging everywhere (although there is more that one MVC framework out there too). I agree with Scott's point about the nature of technical debates, and the acceptance that there are different schools of thought. However, that does not always imply that all schools are equally good solutions to a given problem.

The issue has been though I think not solely about the MVC pattern, it is also about the shift from providing rich client behavior server-side or client-side. In this area the renewed interest in AJAX and the emergence of Javascript libraries like Prototype, script.aculo.us and JQuery have been game changers. And for me those RIA paradigms dovetail better with MVC apps than with Webforms applications. At the same time the growth of REST has meant many have re-engaged with the HTTP protocol and its resource oriented model, have turned attention away from page based approaches to web development toward resource oriented ones. There is a correspondence here, because as the use of client side scripting grows so does the perspective of the server as a resource provider used by the client.

It is in many ways this shift of paradigm that MVC supports better and why using MVP approaches with WebForms is not a 'seperate but equal' answer to modern web development. Its not simply about better conformance to Single Responsibility Principle.

What our frameworks do for us

Our average web framework has some pretty basic requirements - handle requests for resources from the server by returning an appropriate response. In our case this is HTML. The simple nature of this model underlies the success of the web.

To support this model our framework needs to route to an appropriate handler in our code that can read the request. Now we could just interrogate that request to pull out post data or query strings, but writing a lot of that code would get old fast, so it helps if our framework can map between form, params and query string values and part of our object model. That way we can manipulate the variables of the request more easily. Now we have to take an appropriate action in response to the request. Generally this is where most of our code plugs in. We get some data and compose a response, in HTML to return in the response. Now just using Response.Write() to output our HTML becomes hard to maintain, so most of us expect our framework to give us some sort of template so that we can separate the static and dynamic portions of our response.

The MVC pattern enters the fray here when frameworks separate the responsibilities of template to provide view, model to provide response to action, and co-ordination between the two for a request. Criticism of Webforms as lacking effective separation cf concerns is because the aspx file is both responsible for rendering the HTML used as a response and providing the controller for the request. It thus has two reasons to change, because the template changes or because the co-ordination of handling a request changes. These may be orthogonal concerns and make maintenance harder. Some patterns such as MVP try to alleviate this by enforcing separation of these two responsibilities within the framework. this criticism is valid but not complete issue; the significance of 'MVC' frameworks is not solely their better separation of concerns.

Now for sure the devil is in the details, but that's pretty much it.

Bare Bones

'MVC' frameworks such as ASP.NET MVC or Monorail ttend to have a bare bones approach to meeting these requirements. The framework takes requests and calls an action to service them, mapping request to action parameters. We then carry out the appropriate task and render html through a view engine. MVC frameworks add little on top of this paradigm. The big win here is that this makes them simple to learn and easy to use, because the surface area of the API is small. The surface area for ASP.NET MVC is smaller than that for Webforms and is easier for new developers to learn. It also works in harmony with http and thus expectations. The principle of least surprise is important to APIs because it makes them easier to discover. Understand the problem and you are likely led in search of the solution.

Rich Internet Applications

Now ASP.NET MVC etc. allow you to return an HTML response, but HTML has its limitations in that it is static. You need to post a request to the server each time you want some new action to occur. In some cases this 'complete form and submit' model works, but we have become used, from smart clients, to a more dynamic model that provides feedback as we make selections. We expect choosing from one dropdown such as country to restrict choices such as US State vs. UK county or Post Code vs. Zip Code.

Out-of-the-box support in web browsers for dynamic behaviour came in the form of Javascript and manipulation of the DOM. The browser is the smart client in this approach. The issue here is that Javascript development was a challenge for many developers and consequently many development shops. Why? Because folks found client side behaviour did not just require switching to another language, but also learning the DOM, which was also sometimes uncomfortably close to metal for developers weaned on smart client Forms frameworks like Windows Forms, VB, or PowerBuilder. In addition the browser wars meant that the model for programming against the DOM was not the same from browser to browser, further complicating the code that was needed to implement a rich client in the browser. In truth it was expensive. Finally the debugging experience was poor. We were back to tracing the state of variables in order to isolate and fix problems in the browser. For many MIS departments writing sites with a rich client, heavy on javascript, was out-of-reach in other cost or skills.

To solve this problem WebForms introduces the concept of server side controls - essentially shifting the rich interaction to the server. The server side control abstracts the html control from the client side. The benefit is that it allows you a development approach familiar to forms based programmers. You set and get control properties and write handlers to react to events. But as the events are raised client-side you need effectively mirror all of the control state from the client side to the server. The problem here is that html does not share this with you on a post. You also need to record the event raised for the server side too, as a post is all you know about from http. This brings in ViewState, which captures all the state which a post is not giving you. But once it is implemented I can provide all that dynamic behaviour on the server, skipping and jumping over issues like knowledge of Javascipt and the DOM, as well as browser compatibility issues.

Of course we can quickly see that with any complex enough page ViewState will grow. As it is embedded in a page it increases the page weight which can hamper performance In addition because we must do an http post to transfer the state of our application back to the server, and then display the response, events are handled by a page refresh. This has the consequence of making the system slower than one which handles the event locally, giving rise to user complaints of flicker or slow response. In addition if you try to cope by adding some AJAX callbacks from your client the question quickly becomes 'who owns this state' as you may have copies of the state both on the client and in ViewData being marshalled back and forth to the server.

Webforms is also a more complex API than MVC and thus harder for developers to learn. Most of us have been at an interview where we have asked, or been asked the question - what is the Webforms lifecycle? Understanding the stages, where viewdata is available and modifiable is not an insignificant learning challenge.

Given that, for some time I used to recommend building applications using WebForms server-side control model over building applications with client side behaviour. Why? Because of the cost and difficulty of building rich client behaviour in Javascript with the DOM outweighed the cost of learning Webforms.

What Changed?

MVC trades the complexity of server side controls for a simpler programming model, supported by client side controls. The emergence of the new breed of Javascript frameworks like Prototype, JQuery, and script.aculo.us, made it far cheaper to code the client behaviour on the client. The elegance and simplicity of these frameworks, their abstraction of browser API differences, and their rich ecosystem of control providers, lowered the barrier to entry for client-side development providing solutions to common needs such as grids . The availability of many free controls lowers the cost of common UI widgets that have often been the preserve of expensive vendor solutions.

In addition the debugging experience for Javascript has significantly improved from the old trace and dump model with browser plugins such as Firebug and Visual Studio.

With a lower cost it has become commercially viable for more development shops to build rich client applications. Best of breed applications do not suffer from the postback flicker issue because they manipulate state locally on the browser and use AJAX calls to the server. With effective client side development, the user experience is akin to smart clients of yesterday, with none of the distribution problems for central IT departments. This rich experience available for the web lies at the heart of the SaaS revolution.

The MVC model truly shines with AJAX where the target for an AJAX call is just an action on a controller. The affinity to http’s resource based model allows for easy definition of the server side support for rich clients. The advatange of MVC frameworks is the ease with which they dovetail to client-code using frameworks like JQuery. Client-side programming is back, using modern Javascript libraries!

It is this, IMO, which has shifted the balance in favour of MVC. I do not think it any accident that the ASP.NET team shipped JQuery with ASP.NET MVC. I think it was essential to shipping an ASP.NET MVC application that a modern Javascript client library was included to support rich client behaviour on the browser instead of server side.

From my cold dead hands

The attitude of many developers may be ‘you will pry Weforms from my cold dead hands’. The march of progress is threatening to do just that. Much of theresistance is based on prior experiences with the cost of client-side development using Javascript, without understanding that the new frameworks available have significantly lowered the barrier to entry there. In addition, Silverlight opens a second front against Webforms by offering rich client development using XAML. If Javascript does not replace Webforms, then XAML will. Server-side controls had their day. They built careers, companies, and fortunes but they are legacy applications now. Client-side controls have returned with fresh offensives that will see their end. If you are building a new web project today you should be looking at an MVC framework.

For my part the question of Webforms vs. MVC is already an irrelevance. That is yesterday’s fight and victory has been declared despite a few units continuing to fight on. The next war is likely to be between Silverlight and Javascript for ownership of the smart client…

Don't Use Try/Catch

karl — Mon, 25 Jan 2010 15:02:00 GMT

Exception handling has been talked about a lot over the last decade and a half. However, despite a general consensus on how to properly handle exceptions, a divide on usage continues to exist. Improper exception handling is easy to spot, easy to avoid, and is a simple code (and developer) quality metric. I know absolute rules come off as close minded or exaggerated, but as a general rule you shouldn't be using try/catch.

If an exception happens, you need to know about it. If a truly unexpected exception happens, you're better off (most of the time) crashing than letting the application continue. This is particularly true in a web application where you'll only crash 1 thread for 1 user while your site remains accessible. The best way to achieve both is let the exception go unhandled and log the exception in a global exception handler. Too often I see developer writing code which masks errors and make it impossible to build a quality system. Users complain about system instability, and developers are left scratching their heads with no leads on what the problems are.

What's even more frustrating is when framework code swallows exceptions. Take a look at this example, written by Microsoft:

private void LoadImage()
{
    if (this.image != null)
    {
        this.image.Dispose();              
    }
    

    if (source != null)
    {                
        try
        {                  
            source = Path.Combine(Canvas.ApplicationPath, source);                    
            image = new Bitmap(source);                  

           IImagingFactory factory = ImagingFactory.GetImaging();
           factory.CreateImageFromFile(source, out imagingImage);
        }
        catch{}                                                      
    }
}

This is a fundamental piece of code which is part of Microsoft's UI Framework for .NET Compact Framework. The above code is buried within their framework, but through various key APIs is exposed and used extensively. This is simply horrible code. Why would they swallow any exceptions that come out of this code? The above code means that if you try to load an image "images/critical_warning.png" which doesn't exist, the application will continue to work normally. There may be cases where this is the behavior that you want, but those would be edge cases, and they should be decided at the application level, not within the framework.

The only time you should swallow exceptions (catch{..} or catch(Exception){...}) is in your global exception handler to avoid truly fundamental issues (and recursive global exception handling). You should catch specific exception (catch(XmlException){...}) when an exception isn't unexpected and you know that you can safely proceed.

A system that swallows and masks exceptions isn't a healthy system.

A Kick in the Monads – Creating Extended Builders Part III

Matthew.Podwysocki — Mon, 25 Jan 2010 06:05:54 GMT

So far in this series, we’ve covered some of the methods you can implement for custom computation expressions (aka Monads) in F# such as bind and return, as well as exception and resource management. For the last part in the series, we’ll take a look at looping constructs. As we know, F# is a pragmatic multi-paradigm language which supports not only functional features, but imperative ones as well, which include mutability, looping constructs and so on. Just as regular F# supports for and while loops, we have the ability to take advantage of them as well inside of our computation expressions by implementing two methods. Let’s start with the while loop.

Implementing the While Method

In order to enable the while loop construct within F#, we need to implement the While method. This method should have the following signature which takes a guard function which takes no parameters and returns a bool, and a monadic type of unit, and the return is a monadic type of unit. The reason for the unit return is that in imperative programming we typically perform some side effect inside a looping construct such as a while and for loop. That’s not to say we can’t return a value, and we’ll talk about that later.

type Builder = 
  member While : guard : unit -> bool *
                 computation : Monad<unit> ->
                 Monad<unit>

We can write a test to express how this should behave once it has been implemented. In this instance, we want to loop at least once to ensure the loop works and then check our value that has been incremented. Just as well, we should also write a test to express behavior where it should not increment if the guard is never satisfied. But in the mean time, let’s focus on the first scenario.

[<Fact>]
let ``while should increment count``() =
  let count = ref 0
  let r = reader {
    while !count < 1 do
      incr count }
  
  runReader r ()

  areEqual 1 !count

Now the question is, how do we implement this? In the case where our guard function fails, we want to return a monadic type of unit which indicates nothing was done, whereas when it succeeds, we want to bind together our computation and a function which takes no parameters and returns a recursive call to our While loop.

type ReaderBuilder() = 

  member this.While(guard, computation) =
    if guard() then 
      this.Bind(computation, (fun () -> this.While(guard,computation))) 
    else 
      this.Return ()

Now we have the ability to execute any while loop inside our computation expression. For the most part, this implementation is rather boilerplate and can apply to any number of monad implementations. Now, let’s move onto implementing for loops.

Implementing the For Method

Just as we needed to implement the While method to enable while loops in our custom computation expressions, we will need to implement the For method to enable for loops. In order to implement this method, it should conform to the following signature which takes a sequence of any type, and a body which takes an item from the sequence and returns a monadic type of unit.

type Builder =
  member For : sequence : seq<'T> *
               body : ('T -> Monad<unit>) ->
               Monad<unit>

Let’s take a look at how we might use it through the example of a test. In this instance, we will simply iterate over a for loop and increment a count and then check its result. In another test, we should also have an empty collection we try to iterate and check that it does not increment.

[<Fact>]
let ``for should increment count``() =
  let count = ref 0
  let r = reader {
    for i = 0 to 1 do
      incr count }
  
  runReader r ()

  areEqual 1 !count

Now, how might we pull this one off? In order to do this, we must introduce another method, called Delay. This method helps us delay any side effects from happening until they are absolutely needed. Unlike Haskell, F# is an eager functional programming language, so such constructs are necessary. Let’s look at the signature required for the Delay method below, which takes no parameters and returns a monadic type of T.

type Builder =
  member Delay : unit -> Monad<'T>

Knowing this, we can go ahead an implement both our Delay and For methods. In the Delay method, we simply bind a monadic wrapped unit with our function, when then in turn will return our Reader<’R,’T>. Next, we have a For method which takes a sequence and a body to run against each item. We can reuse the Using method to ensure proper disposal for our IEnumerator<T> and then call While with a function of whether we can move next, and then a delayed function which runs the body function against the current item. Below is how the implementation should look.

type ReaderBuilder() =

  member this.Delay(f) =
    this.Bind(this.Return (), f)

  member this.For(sequence : seq<_>, body) =
    this.Using(sequence.GetEnumerator(), 
      (fun enum -> 
         this.While(
           (fun () -> enum.MoveNext()), 
           this.Delay(fun () -> body enum.Current))))

Now that we have the looping constructs defined, let’s look at another way of thinking about looping.

Looping and Yield Methods Together

In addition to the style we’ve shown in this series with our Bind/Return for our non-collection types, we also have the ability to define a a yield statement which looks and acts much like the C# equivalent. Commonly, this yield is used in conjunction with some sort of looping construct. For example, this construct is already available on sequence expressions inside F#.

seq { for i = 1 to 10 do
        yield i * 25 }

Such constructs make a lot of sense when we’re thinking about interactive and reactive collections, the latter of which we’ll get to later when we’re talking about the Reactive Extensions Observable monad. In order to enable the Yield behavior, we simply need to implement the Yield method which should look like the following:

type Builder =
  member Yield : value : 'T -> Monad<'T>

The actual implementation of this for our Reader (should we decide to implement it) should look no different than our Return method. To either call return or yield is simply a matter of style when dealing with collection versus non-collection based computation expressions. Just as we defined the ReturnFrom method in a previous post to enable the return! keyword, we can also follow the same logic to implement the YieldFrom method which should have the following signature.

type Builder =
  member YieldFrom : comp : Monad<'T> -> Monad<'T>

Together, this enables such behavior as getting all the files from a directory like the following:

open System.IO

let rec getFiles dir = seq {
  for file in Directory.GetFiles dir do yield file
  for subDir in Directory.GetDirectories dir do yield! getFiles subDir }

Just as well, we could use the yield to show Observable collections such as events:

let getMouseMove() = obs {
  for md in form.MouseDown do
    for mm in form.MouseMove |> Observable.until form.MouseUp do
      yield mm }

It’s a matter of style which one we use, whether we are specifying collection like intent or not. With that, this should wrap up how to implement a custom computation expression. Much of this code, outside of Bind/Return TryCatch/TryFinally is boilerplate and can apply to any number of computation expression instances such as the State, Reader, Error, Maybe, and some yet to come such as the mother of all monads, the Continuation Monad, and of course the Observable Monad.

Conclusion

Besides the usual Bind and Return functions that we’ve talked about extensively here, there are quite a few other constructs which allow for rich programming models inside our computation expressions that we just explored. Whereas LINQ has a rather linear programming model based upon monads, the computation expression includes richer features which include exception handling, control statements, loops, and side effects.

Still left in this series, we’ll dive into the root of both the F# Async Workflows and Reactive Extensions for .NET, the Continuation Monad as well as the Observable one as well.

Url Resolution in FubuMVC

Jeremy D. Miller — Mon, 25 Jan 2010 04:34:00 GMT

Continuing the thread from my earlier update on the “Fubu Reboot.” In an MVC web application (I think this really could apply to WebForms as well, but not to the same extent) you frequently need to resolve the Url that points to a specific subject. In our application at Dovetail, we have the route pattern: “sites/edit/{Id}” for the page that edits a “Site” object. When we place links in the views for a given “Site” object, we need to replace “{Id}” in the route with the value of the Site.Id property. In another circumstance, we have the routing pattern “query/for/{QueryName}/{QueryParam1}” for a controller action that takes in this object as its single argument:

    // The [RouteInput] attributes are *a* way to direct Fubu to 
    // make these properties by automatically scanned as part of the 
    // route pattern.
    // This should only be necessary in exception cases
    // My hope is that conventions take you 90% of the way home
    public class QueryForRequest
    {
        [RouteInput]
        public string QueryName { get; set; }
 
        [RouteInput("")]
        public string QueryParam1 { get; set; }
    }

At many, many times in our application we need to determine the Url string that points to a particular subject or occasionally to a controller action. At the same time, it would be very, very nice to keep the individual controllers and views ignorant of exactly what those Url patterns happen to be in order to make them easier to change. In FubuMVC, that’s all done with the IUrlRegistry interface that is automatically placed into your IoC container:

    // This service is injected into your IoC tool of choice as a singleton
    // to give you access to url's in a type safe way
    // Please note that this implementation in no way, shape, or form
    // locks you into a rigid url structure
    public interface IUrlRegistry
    {
        string UrlFor(object model);
        string UrlFor(object model, string category);
        string UrlFor<TController>(Expression<Action<TController>> expression);
 
        string UrlForNew<T>();
        string UrlForNew(Type entityType);
 
        // Not sure these two methods won't get axed.  They could just be extension methods in Dovetail code
        string UrlForPropertyUpdate(object model);
        string UrlForPropertyUpdate(Type type);
 
        string UrlFor(Type handlerType, MethodInfo method);
    }

In the FubuMVC model, we’re basically assuming that controller actions (Fubu actions don’t have to be on special Controller classes, btw) take in 0 or 1 objects as their single input. Taking another step, if you make the input model types unique per controller action, FubuMVC can actually use that type to “know” what controller action receives that type. Therefore, when I need the Url string that points to a particular Site object, I just pass in that Site object to the UrlRegistry.For(object) method. In the more complex case of the QueryForRequest object above, I do the exact same thing – even though QueryForRequest clearly points to a different Route. For controller actions that don’t take in any input arguments (think HomeController.Index()), you can still use UrlRegistry.UrlFor<HomeController>(x => x.Index()).

For those of you familiar with ASP.Net MVC’s model, here’s some other facts:

The lookup of a Url for a Controller Type / Method combination makes no, let me repeat that, no assumptions about the Url pattern. SomethingController.Method1() does not imply that the Url is “something/method1.” FubuMVC is literally hashing the exact Route pattern for each Controller action and looks up the exact Url at runtime.
The call to UrlFor() is completely independent of whether or not the Route in question was registered as part of the main application or as part of an Area/Slice. Unlike MVC2, when you’re determining the Url to a certain controller action or input object, you do not have to worry about where I think the MVC team thoroughly screwed up their Area support and I’d surely hope they scrap it for something better in MVC3. If you’re using the MVC framework today, I’d strongly recommend you use the bits in MvcContrib instead of MVC2 for areas.
No magic strings of any kind. Anywhere.

Lastly,

The Url resolution is static typed. That’s valuable to help prevent coding mistakes and Intellisense is also nice. Honestly, my favorite part is how much more traceable it makes the code rather than relying on strings. One quick CTRL-B shortcut takes you the the controller action behind the Url. In the case of finding the Url for an object, it’s one more bounce with CTRL-ALT-F7 (one of my favorite R# shortcuts). In real usage, we have convenience methods on our view types to get at action urls, as well as consuming the IUrlRegistry in our FormFor() and ActionUrlFor() type HtmlHelpers.

Now that we mostly rely on IUrlRegistry.For(object), IUrlRegistry is relatively easy to mock in most tests. If your tests have to rely on an Expression in IUrlRegistry.UrlFor<T>(x => Method()), I'd go for some sort of hand rolled stub.

Ok, this may be vague, so please ask question. Also, this stuff isn’t locked down, so we can actually change it to suit. And I won’t even get all paternalistic on you telling you that “UrlFor() doesn’t really mean UrlFor()” if you don’t like the API.