Working with the Dynamic Type in C#
https://www.red-gate.com/simple-talk/dotnet/c-programming/working-with-the-dynamic-type-in-c/?utm_source=simpletalkdotnet&utm_medium=pubemail&utm_content=20181127-slota1&utm_term=simpletalkmain
by Camilo Reyes
15 October 2018
Dynamic types were introduced in .NET 4. Dynamic objects let you work with structures such as JSON documents whose composition may not be known until runtime. In this article, Camilo Reyes explains how to work with dynamic types.
The introduction of the dynamic keyword in .NET 4.0 brings a paradigm shift for C# programming. For C# programmers, dynamic behavior on top of a strong type system can feel wrong. It does seem like a step backward when you lose type safety during compilation.
Dynamic programming can leave you exposed to runtime errors. Declaring a dynamic variable that can mutate during execution is scary. Code quality suffers when developers make the wrong assumptions about the data.
For C# programmers, it is logical to avoid dynamic behavior in code. There are benefits to the classical approach of having strong types. Good feedback on data types through type checking is paramount to working programs. A good type system communicates intent and reduces ambiguity in code.
With the introduction of the Dynamic Language Runtime (DLR), what does this say about C#? .NET offers a rich type system useful for writing enterprise grade software. Let's take a closer look at the dynamic keyword and explore what it can do.
Type Hierarchy
Every type in the Common Language Runtime (CLR) inherits from System.Object. Now, read that last sentence again until you internalize this. This means the object type is the common parent to the entire type system. This fact alone aids us when we get to more exotic dynamic behavior. The idea here is to develop this 'code-sense', so you know how to navigate around dynamic types in C#.
To demo this, you can write the following program:
| | Console.WriteLine("long inherits from ValueType: " +
typeof(long).IsSubclassOf(typeof(ValueType))); |
I will omit using statements until the end of this article to keep code samples focused. Then, I will go over each namespace and what it does. This keeps me from having to repeat myself and provides an opportunity to review all types.
The code above evaluates to True inside the console. The long type in .NET is a value type, so it's more like an enumeration or a struct. The ValueType overrides the default behavior that comes from the object class. ValueType descendants go on the stack which have a short lifetime and are more efficient.
To validate that ValueType inherits from System.Object, do:
| | Console.WriteLine("ValueType inherits from System.Object: " +
typeof(ValueType).IsSubclassOf(typeof(Object))); |
This evaluates to True. This is an inheritance chain going back to System.Object. For value types, there are at least two parents in the chain.
Take a look at another C# type that descends from System.Object, for example:
| | Console.WriteLine("string inherits from System.Object: " +
typeof(string).IsSubclassOf(typeof(Object))); |
This code spits out True in the console. Another type that inherits from the object are reference types. Reference types get allocated on the heap and undergo garbage collection. The CLR manages reference types and deallocates them from the heap when necessary.
Look at the following figure so you can visualize the CLR's type system:
Both value and reference types are the basic building blocks of the CLR. This elegant type system predates both .NET 4.0 and dynamic types. I recommend keeping this figure in your mind's eye when you work with types in C#. So how does the DLR fit into this picture?
The Dynamic Language Runtime
The Dynamic Language Runtime (DLR) is a convenient way to work with dynamic objects. For example, say you have data as XML or JSON where the members aren't known ahead of time. The DLR lets you use natural code for working with objects and accessing members.
For C#, this enables working with libraries where types aren't known at compile time. A dynamic type eliminates magic strings in code for a natural API. This unlocks dynamic languages that sit on top of the CLR such as IronPython.
Think of the DLR as supporting three primary services:
To see how the DLR and CLR fit together, review this figure:
The DLR sits on top of the CLR. Recall that I said every type descends from System.Object. Well, I did scope it to the CLR but what about the DLR? Test this theory with this program:
| | Console.WriteLine("ExpandoObject inherits from System.Object: " +
typeof(ExpandoObject).IsSubclassOf(typeof(Object)));
Console.WriteLine("DynamicObject inherits from System.Object: " +
typeof(DynamicObject).IsSubclassOf(typeof(Object))); |
Both ExpandoObject and DynamicObject evaluate to True in the command line. Think of these two as the basic building blocks for working with the dynamic type. This paints a clear picture of how both runtimes fit together.
A JSON Serializer
One problem the dynamic type solves is when you have a JSON HTTP request where members aren't known. Say there is this arbitrary JSON you want to work within C#. To solve for this, serialize this JSON into a C# dynamic type.
I'll use the Newtonsoft serializer, you can add this dependency through NuGet, for example:
| | dotnet add package Newtonsoft.Json –-version 11.0.2 |
You can use this serializer to work with both ExpandoObject and DynamicObject. Explore what each dynamic type brings to dynamic programming.
The ExpandoObject Dynamic Type
The ExpandoObject is a convenience type that allows setting and retrieving dynamic members. It implements IDynamicMetaObjectProvider which enables sharing instances between languages in the DLR. Because it implements IDictionary and IEnumerable, it works with types from the CLR. This allows an instance of the ExpandoObject to cast to IDictionary, for example. Then enumerate members like any other IDictionary type.
To use the ExpandoObject with an arbitrary JSON, you can write the following program:
| | var exObj = JsonConvert.DeserializeObject<ExpandoObject>(
"{\"a\":1}") as dynamic;
Console.WriteLine($"exObj.a = {exObj?.a}, type of {exObj?.a.GetType()}"); |
This prints 1 and long in the console. Note that although it is a dynamic JSON, it binds to C# types in the CLR. Because the number type isn't known, the default serializer picks the biggest type which is a long. Note that I safely cast serializer results into a dynamic type with null checks. The reason is the serializer returns an object type from the CLR. Because ExpandoObject inherits from System.Object, it can be unboxed into a DLR type.
To be fancy, enumerate exObj with IDictionary:
| | foreach (var exObjProp in exObj as IDictionary<string, object>
?? new Dictionary<string, object>())
{
Console.WriteLine($"IDictionary = {exObjProp.Key}: {exObjProp.Value}");
} |
This prints IDictionary = a: 1 in the console. Be sure to use string and object as the key and value types. Otherwise, it will throw a RuntimeBinderException during the conversion.
The DynamicObject Dynamic Type
DynamicObject offers precise control over the dynamic type. You inherit from this type and override dynamic behavior. For example, you can define how to set and get dynamic members in the type. The DynamicObject lets you choose which dynamic operations to implement through overrides. This grants easier access than a language implementer which implements the IDynamicMetaObjectProvider. It is an abstract class, so it inherits from this instead of instantiating it. This class has 14 virtual methods which define dynamic operations on the type. Each virtual method allows overrides that specify dynamic behavior.
Say you want precise control over what gets into the dynamic JSON. Although you do not know the properties ahead of time, with a DynamicObject, you get control over the type.
Let's override three methods, TryGetMember, TrySetMember, and GetDynamicMemberNames:
| | public class TypedDynamicJson<T> : DynamicObject
{
private readonly IDictionary<string, T> _typedProperty;
public TypedDynamicJson()
{
_typedProperty = new Dictionary<string, T>();
}
public override bool TryGetMember(GetMemberBinder binder, out object result)
{
T typedObj;
if (_typedProperty.TryGetValue(binder.Name, out typedObj))
{
result = typedObj;
return true;
}
result = null;
return false;
}
public override bool TrySetMember(SetMemberBinder binder, object value)
{
if (value.GetType() != typeof(T))
{
return false;
}
_typedProperty[binder.Name] = (T)value;
return true;
}
public override IEnumerable<string> GetDynamicMemberNames()
{
return _typedProperty.Keys;
}
} |
C# generics strong type the _typedProperty in a generic way which drives member types. This means the property type comes from the T generic type. Dynamic JSON members are inside a dictionary and only store the generic type. This dynamic type allows for a homogeneous set of members of the same type. Although it allows a dynamic set of members, you can strongly type the behavior. Say you only care about long types from an arbitrary JSON:
| | var dynObj = JsonConvert.DeserializeObject<TypedDynamicJson<long>>(
"{\"a\":1,\"b\":\"1\"}") as dynamic;
Console.WriteLine($"dynObj.a = {dynObj?.a}, type of {dynObj?.a.GetType()}");
var members = string.Join(",", dynObj?.GetDynamicMemberNames());
Console.WriteLine($"dynObj member names: {members}"); |
As a result, you'll see a single property with a value of 1 because the second property is a string type. If you change the generic type to a string, it will pick up the second property instead.
Type Results
Quite a bit of ground has been covered so far; here are some highlights:
Look at the results captured in a console:
There Will Be Unit Tests
For unit tests, I'll use the xUnit test framework. In .NET Core, you add a test project with the dotnet new xunit command. One problem that becomes evident is mocking and verifying dynamic parameters. For example, say you want to verify that a method call exists with dynamic properties.
To use the Moq mock library, you can add this dependency through NuGet, for example:
| | dotnet add package Moq –-version 4.10.0 |
Say you have an interface and the idea is to verify it gets called with the right dynamic object:
| | public interface IMessageBus
{
void Send(dynamic message);
} |
Ignore what implements this interface. Those implementation details aren't necessary for writing unit tests. This will be the system under test:
| | public class MessageService
{
private readonly IMessageBus _messageBus;
public MessageService(IMessageBus messageBus)
{
_messageBus = messageBus;
}
public void SendRawJson<T>(string json)
{
var message = JsonConvert.DeserializeObject<T>(json) as dynamic;
_messageBus.Send(message);
}
} |
You can make use of generics, so you can pass in the dynamic type for the serializer. Then call the IMessageBus and send the dynamic message. The method under test takes a string parameter and makes a call with a dynamic type.
For the unit tests, encapsulate it in a class MessageServiceTests. Begin by initializing mocks and the service under test:
| | public class MessageServiceTests
{
private readonly Mock<IMessageBus> _messageBus;
private readonly MessageService _service;
public MessageServiceTests()
{
_messageBus = new Mock<IMessageBus>();
_service = new MessageService(_messageBus.Object);
}
} |
The IMessageBus gets mocked using a C# generic in the Moq library. Then create a mock instance using the Object property. The private instance variables are useful inside all unit tests. Private instances with high reusability add class cohesion.
To verify a call with Moq, an intuitive approach is to try to do:
| | _messageBus.Verify(m => m.Send(It.Is<ExpandoObject>(
o => o != null && (o as dynamic).a == 1))); |
But alas, the error message you'll see is this: "An expression tree may not contain a dynamic operation." This is because C# lambda expressions do not have access to the DLR. It expects a type from the CLR which makes this dynamic parameter hard to verify. Remember your training and tap into your "code-sense" to solve this problem.
To navigate around what seems like a discrepancy between types, use a Callback method:
| | dynamic message = null;
_messageBus.Setup(m => m.Send(It.IsAny<ExpandoObject>()))
.Callback<object>(o => message = o); |
Note the callback gets typed to a System.Object. Because all types inherit from the object type, you're able to make the assignment into a dynamic type. C# can unbox the object inside the lambda expression into a dynamic message.
Time to write a nice unit test for the ExpandoObject type. Use xUnit as the testing framework, so you'll see the method with a Fact attribute.
| | [Fact]
public void SendsWithExpandoObject()
{
// arrange
const string json = "{\"a\":1}";
dynamic message = null;
_messageBus.Setup(m => m.Send(It.IsAny<ExpandoObject>()))
.Callback<object>(o => message = o);
// act
_service.SendRawJson<ExpandoObject>(json);
// assert
Assert.NotNull(message);
Assert.Equal(1, message.a);
} |
Test with a DynamicObject type, reusing the TypedDymaicJson that you've seen before:
| | [Fact]
public void SendsWithDynamicObject()
{
// arrange
const string json = "{\"a\":1,\"b\":\"1\"}";
dynamic message = null;
_messageBus.Setup(m => m.Send(It.IsAny<TypedDynamicJson<long>>()))
.Callback<object>(o => message = o);
// act
_service.SendRawJson<TypedDynamicJson<long>>(json);
// assert
Assert.NotNull(message);
Assert.Equal(1, message.a);
Assert.Equal("a", string.Join(",", message.GetDynamicMemberNames()));
} |
Using C# generics, you can swap dynamic types for the serializer while reusing code. The Callback method in Moq allows you to make the necessary hop between type systems. Having an elegant type hierarchy with a common parent turns to be a lifesaver.
Using Statements
The following using statements are part of the code samples:
Conclusion
The C# dynamic type may seem scary at first but has benefits on top of a strongly typed system. The DLR is where all dynamic operations occur and interoperate with the CLR. Type inheritance makes it easy to work with both type systems at the same time. In C#, there is no animosity between dynamic and static programming. Both type systems work together to solve dynamic problems in a creative way.
