Tomorrow night, I’m giving my presentation discussing not only how, but when to consider using the dynamic features of C# 4 and VB (forever). If you attend the presentation, you can download the samples and slides from my download page. Part of the key in this presentation is discussing the Why as compared to the simpler How of Dynamic. Here are some of my top reasons to use the dynamic features:
When trying to use unit testing, the compiler often limits the ability to follow-through on the test first methodology because you have to write at least a bare implementation before your tests and solution can compile. If you declare your objects as dynamic in your tests, you can write all of your tests without having to write the implementation. Naturally, the tests will fail at this point, but with test driven development, your tests should fail until you have written your implementation.
One of the main things to understand if you are using dynamic types is that you no longer have your compiler acting as a unit-test, checking your code to make sure that the methods and types that you are trying to consume actually exist. Instead, you need to take extra care to fully unit test your code to ensure that it truly works the way you intend. Frankly, I don’t care what testing framework you use or how much code coverage you have, just do it!
One of the traditional advantages VB has had over the C based languages is the late binding ability to work naturally with COM interfaces like those exposed in Office. Using dynamic in C# 4, gives the curly-bracket world to work with office with less ceremony. VB still has an edge in that it can retain intellisense support because of the late binding rather than “object with dynamic semantics” typing that C# utilizes.
Flexible data structures
There are times when building frameworks where you might not know the structure of your data at compile time. I’ve written before about how to use the dynamic features for parsing CSV files. The same technique can be used to parse XML files as well. If you’ve used DataSets in the past, this is another such framework which currently uses strings as parameters to access tables and fields as objects. With Microsoft.Data in the WebMatrix libraries, Microsoft introduced a dynamic implementation over datasets as well, simplifying the programming model there as well. David Fowler wrote a series of blog posts introducing Microsoft.Data last year.
Scripting and DLR
Often, applications need the ability to allow for end user customization without the need to re-compile the application. With the DLR integration, you can add these script extension points in your application so that users can write code in Python, Ruby or any other DLR supported language. As long as you add the hooks in your application, you can take advantage of the user’s scripted changes.
In addition, the web contains a plethora of python and ruby code components that you can include in your .Net application by interacting with them via the DLR. Taking advantage of mature and well tested modules is often better than trying to re-invent the wheel yourself. Don’t fall into the trap of the “Not invented here” syndrome.
Increased separation of concerns
By using dynamic connections between your types, you can have components interact without needing to share version compatible interfaces and contracts. As long as your modules follow established conventions, it can work nicely without relying on the ceremony required otherwise. I demonstrated a while back how to connect MVC 1 views with anonymous types using VB’s late binding. More recent versions of MVC use dynamic features by default to bind to views with C# as well.
Along similar lines, Robert McCarter demonstrated using DynamicObject in the ViewModel of a MVVM pattern to eliminate the need to delegate all of the property Set/Get pairs between the View and the Model.
I’m sure this is just the tip of the iceberg of areas to use dynamic features. Can you thinq of others? The nice thing about VB and C# is that you can scope the use of dynamic features to just those parts of the application that benefit from them. This way you get the best of both worlds: the performance, tooling, and compiler support of static languages and simplicity, no compilation, implicitly typed objects and methods of dynamic languages.
Ultimately, when I have to choose between the two, I return to the mantra from Erik Meijer, et. al.