You are on page 1of 3

4/10/2015 Tales 

from the Evil Empire ­ Clay: malleable C# dynamic objects – part 1: why we need it

Clay: malleable C# dynamic objects –
part 1: why we need it
Tuesday, August 17, 2010
.NET (/bleroy/Tags/.NET)   ASP.NET (/bleroy/Tags/ASP.NET)   C# (/bleroy/Tags/C%23)   Clay (/bleroy/Tags/Clay)
CodePlex (/bleroy/Tags/CodePlex)   Dynamic languages (/bleroy/Tags/Dynamic%20languages)   JSON (/bleroy/Tags/JSON)
Orchard (/bleroy/Tags/Orchard)

When trying to build the right data structure in Orchard
(http://orchardproject.net/) to contain a view model to which multiple entities
blindly contribute, it became obvious pretty fast that using a dynamic
structure of sorts was a must.

What we needed was a hierarchical structure: a page can have a list of blog
posts and a few widgets, each blog post is the composition of a number of
parts such as comments, comments have authors, which can have avatars,
ratings, etc.

That gets us to the second requirement, which is that multiple entities that
don’t know about each other must contribute to building that object graph.
We don’t know the shape of the graph in advance and every node you build
is susceptible to being expanded with new nodes.

The problem is that C# static types are not that much fun to build with those requirements.

You could use an XML DOM kind of API with ChildNodes and Attributes collections and NodeName and
Value properties and that would absolutely work.

But I think most people would agree that any long term exposure to this style of API is a serious reason
for depression that has sucked the will to live out of so many developers we don’t want to go there
unless a gun is pointed to our heads.

The main reason why those APIs are so dreadfully boring is that they give you access to the metadata
first and hide access to the actual data (which is what you really care about) under secondary APIs such
as Value.

The value of a node in an object graph is the one thing you care about the most. The second thing you
want easy access to is the children of the node. You want to be able to access them by index or by
name.

Honestly, which one would you rather write?

node.Attributes["rating"].Value

(http://11011.net/software/vspaste)
or:

https://weblogs.asp.net/bleroy/clay­malleable­c­dynamic­objects­part­1­why­we­need­it 1/3
4/10/2015 Tales from the Evil Empire ­ Clay: malleable C# dynamic objects – part 1: why we need it

node.rating

(http://11011.net/software/vspaste)
Yeah, I thought so. The first option feels almost like using reflection to do simple property dereferencing.

OK, so it should be clear by now that the reason why XML APIs are so un­fun in C# is that static
languages hate unpredictability and want to know everything about an object at compile­time. They
accept what is known in advance (nodes have meta­data that is stable in structure) and relegate what’s
unknown to properties.

In other terms, you end up with the real object being a property of the meta­data structure, whereas the
meta­data should be a property of the object.

Before I conclude, I want to say a word about object initializers, which have been around for a while and
are commonly used to build fuzzy option parameters like this:

Html.TextBoxFor(m => m.CurrentUser, new {
  title = "Please type your user name",
  style = "float:right;"
})

(http://11011.net/software/vspaste)
It should be noted that these anonymous objects, while very flexible at creation time, are basically
constants so once you’ve built them, you cannot add new properties or methods to them, which makes
them unsuitable for our use­case.

Fortunately for us, C# 4.0 has a great new keyword ready for all kinds of abuse: dynamic
(http://msdn.microsoft.com/en­us/library/dd264736.aspx).

In part 2 (http://weblogs.asp.net/bleroy/archive/2010/08/18/clay­malleable­c­dynamic­objects­part­
2.aspx), I’ll show how Clay (http://clay.codeplex.com), a small library that Lou (http://whereslou.com/)
wrote, is solving our problem in a very nice and elegant way.

The Clay library: http://clay.codeplex.com (http://clay.codeplex.com)

Part 2:
http://weblogs.asp.net/bleroy/archive/2010/08/18/clay­malleable­c­dynamic­objects­part­2.aspx
(http://weblogs.asp.net/bleroy/archive/2010/08/18/clay­malleable­c­dynamic­objects­part­2.aspx)

3 Comments
Really interesting stuff going on here. This functionality combined with document store databases
will open a whole new world to C# programmers. 
—  Mike Hamrah (http://www.michaelhamrah.com/blog) ­ Thursday, August 19, 2010 3:55:11 PM (/bleroy/clay­malleable­c­
dynamic­objects­part­1­why­we­need­it#comment­1011)

https://weblogs.asp.net/bleroy/clay­malleable­c­dynamic­objects­part­1­why­we­need­it 2/3
4/10/2015 Tales from the Evil Empire ­ Clay: malleable C# dynamic objects – part 1: why we need it

I would choose: 
node.Attributes["rating"].Value 

because then I could make it: 
node.Attributes[someVariable].Value 

and have it do other work. 
—  Donald ­ Tuesday, May 10, 2011 12:45:44 AM (/bleroy/clay­malleable­c­dynamic­objects­part­1­why­we­need­it#comment­
1013)

@Donald: you can get that result by implementing your own Clay behavior. 
—  Bertrand Le Roy (http://weblogs.asp.net/bleroy/) ­ Tuesday, May 10, 2011 4:02:17 AM (/bleroy/clay­malleable­c­
dynamic­objects­part­1­why­we­need­it#comment­1014)

Comments have been disabled for this content.

Terms Of Use (http://www.asp.net/terms­of­use) ­ Powered by Orchard (http://www.orchardproject.net)

https://weblogs.asp.net/bleroy/clay­malleable­c­dynamic­objects­part­1­why­we­need­it 3/3

You might also like