I'm now planning on using dynamic in automated UI tests. Some UI elements are defined based on runtime information. These will be accessible in tests as dynamic properties, like staticly defined elements (as opposed to GetDynamicElement("name") ) to beautify the testing interface. The performance shouldn't matter - UI testing steps take very long anyway.
I'd be interested to see how this works with operators performance-wise. A common use case I find that people leverage dynamic for is older versions of C# (i.e. pre-generic math) when they wish to, for example, add two enum members together using only generic type constraints (where T : struct, Enum). There's a multitude of ways one could use (assume integer and cast - doesn't work if the enum is 'ulong' for example; use cached reflection to retrieve the correct add method; emit and cache IL; and, for a lot of people the easiest, use dynamic).
I use dynamic only in the form of ViewBag that is in Web Applications. It mades communication between server and client easier. I mainly use it for giving a title to webpage dynamically.
In 20 years of writing C# code I've never once used dynamic. If anything, this video showed me that the performance of dynamic is way better than I would have guessed. I don't see myself starting to use it though - it's just not the right solution to the kinds of problems I need to solve in C#. Unless I decide to host IronPython in an app, which it turns out, I just might for a current project - that's what dynamic was made for and is likely the only thing I would ever use it for.
I use dynamic extensively in unit tests. It really helps in truly doing test-first as it will compile fine as a dynamic and explode during the test causing it to be red. It's a minor thing, but I've really come to love the flow. That and dynamic language integration as you mentioned are the only places I've ever used it.
How you mapping complex queries to data model? I always return my complex queries to IEnumerable because it's too complicated to mapping such queries to data model
I'm surprised you didn't mention the reading and writing of JSON and using dynamic. I like it as JSON and versioning isn't a real thing without schemas. I read what is provided, and use a string,dynamic dictionary to hold the key value pair.
I use it mostly when endpoint http response with json does not have strict structure and may vary from request to request, for other situations I prefer to create definition for response explicitly.
I've used dynamic in a couple of scenarios moderately recently. The first (and main one) was when I was working with an Excel add-in that had to work on multiple versions of Excel, but with PIAs that effectively became incompatible across versions based on the COM object returned from Excel. Complex solution probably involved two DLLs in different domains (when was the last time you needed to use global:: before a namespace def?). That would have been horrible and it was a relative edge case so dynamic + try/catch/notify worked. The second was in a set of helper methods for working with reflection. Using dynamic in an unusual scenario enabled me to avoid numerous headaches around mapping types correctly for the general case. Basically it was acting like Object but in a scenario where the called method took or returned a strict (but unknown and unspecifiable, typically because of accessibility specifiers) type. Passing around a dynamic meant that known methods could be called even if they had an internally typed parameter.
Sometimes you don't have much choice and you're working with truly dynamic data that you have to represent somehow, either as a Dictionary or some other means e.g. a tagged data structure. I've just worked on a system that has an API taking in a tagged structure i.e. a type that has a Type member and a Data member. This API has no idea what it will be working with, it's function is to take this data and store the JSON string in the database and also retrieve it from the database and at some point the program will have the dynamic data serialized into a known type. I once wrote a small 2D game engine in C++ and it had a Lua scripting interface that exposed some of the C++ classes. The Lua primitives had to be converted into C++ primitives at runtime, the data was pushed onto a shared stack whereby Lua function calls push their args onto this stack when calling into the C++ functions and C++ pushes back any return values back to Lua. Sometimes data is in a raw format, it's just bytes and that's all you know about it at the time. Usually the data goes through some pipeline that converts the data into known types but there is an intermediary stage where you have truly dynamic runtime data and it has to be represented somehow be it a 'dynamic' object or a simple void* and size_t. If you interface with other language runtimes, you will inevitably have to convert the primitive or user types between these runtimes, but there's not many other legitimate reasons to be using dynamic. If you can possibly know the type at compile time (even if you have to use some nullable fields) it's far better than having runtime known only values.
I had a situation where I wanted to write a Visitor pattern implementation for a graph of entities which I could not control. So I couldn't add .Visit() methods to each entity, to call back in to the visitor.Accept() methods with complete type information. So what I ended up with was using dynamic: "((dynamic)visitor).Accept((dynamic)entity)". The first dynamic told the compiler to choose and bind the .Accept() method override at runtime, and the second dynamic told the compiler to use the runtime type of the entity object as the argument. It worked like a charm and the performance wasn't even too bad. Unfortunately sonarqube complained about all those .Accept() methods apparently being unreferenced (even though they were all covered by unit tests, so they were clearly getting called!). I'm not recommending this strategy to anybody else, just pointing out that dynamic has some uses when other methods of solving problems fail because of lack of compile-time type info.
I think it would be cool if C# added a feature that allowed use of ExpandoObject and similar things *without the dynamic keyword*. Because dynamic delegates all the binding to runtime, but in the case of ExpandoObject, it should be possible to bind all property access to method calls on IDynamicMetaObjectProvider, at compile-time.
I remember I used dynamic once as a method parameter to access a property on multiple types that had the same type and name, I assume I couldn't change the objects I was dealing with to implement an interface.
The only time that I needed to use dynamic type in C# was interoperability calls to an application written in VB6. I use reflection when calling C# objects that I don't know the type of the caller.
In my case I was using ExpandoObjects in a solution which needed to retrieve multiple .CSV files where each one of them could have a different header (20/30 header possibilities). I used CSVHelper to map the needed properties with the help of a dictionary to determine the type of header then created an object with some properties including the header and the csv values as a json. Then, when needed to display the multiples .CSV lines objects in a graphical interface with Blazor, because I wanted to use the same component for each possible .CSV type, I've made the decision when retrieving the object from the database to instanciate the json as an ExpandoObject. Because the ExpandoObject was mainly for Reading purposes I didn't need to know it's properties in advance. I've also made dynamic search fields based on this ExpandoObject and it work's perfectly. Anyway, I'm not sure if I would be able to do something more cleaner and maintenable for my company if I used a lot of conditions in order to achieve the same result.
I use dynamic with numerics. Before INumeric, if you had two numeric types, you couldn't easily multiply or add without it. It's still not that easy because if you have two different numeric types like int vs double, multiplying them when their type is known is easy, but if their type is unknown, dynamic is the only way still (I'm aware of).
I've found exactly only one application of dynamic in all my codebase, but it is really very efficient. I am using it in one very low level place where I invoke method over reflection and get result as Task, then I await that task and want to get result if it is generic task and null if not, I just do this ((dynamic) task).Result and it is magically returns result in minimal possible time. This time is comparable to cached reflection and even slightly better, but it needs no caching at all, and I don't want to apply caching in that place, cause it can outcome in caching almost every property and method of every type in whole application. I use reflection cache only in places where diversity of cached types is small and controlled, but in such abstract and hot path in app dynamic does it's best.
A (very niche) use-case I've enjoyed with dynamic is when dealing with direct json, but you're unable/don't want to de-serialize it directly to a type (for whatever reason). If you're looking for a key regardless, and it fails, that'll fail at runtime either way. So doing myJsonObject.MyProperty from a JObject reads a bit better than trying to GetProperty() on everything with Newtonsoft/etc. That being said, that is the only use-case I've found where it didn't feel like I was introducing a complete anti-pattern.
I once had a project where I had a "compiler" that would read reflection info, and based on that info, emit IL code for dynamic invokation of methodinfo, and cache that code to a delegate. To my surprise, the results of benchmarks (just the calls, not the emmitting part) showed that the call speed was almost as fast as a regular delegate call! I basically had found a way to create more efficient dynamic calls to methodinfo. I am so sad that I lost the project (not in cloud, not in my comp, nowhere). But I can rewrite it again sometime.
I only ever had to use Dynamic in one case in my previous job and that was to call a badly written php endpoint where in some cases it would return an array of something and in some cases it would return an object of something else. So instead of writing truly complicated code to read the result I just used the dynamic to parse it from json and then move by mapping it into an appropriate poco object. I was making an adapter between that endpoint and Dynamics CRM back then.
I don't use dynamic, but my codebase has a lot of places where I dynamically call methods. I try to cache them into delegates but there are places where I need to create an object array to invoke the methods. I'll look into using dynamic for this case.
you could instead use expressions to generate a method invoker and compile it at runtime. It would be strongly typed, so after caching it the invocation would be alloc-free and most likely faster than any other method of dynamic access
Interesting video. Currently I'm using dynamic to operate with SharePoint lists through Microsoft graph since people can just keep adding or removing columns to those and I always need to get all data available.
I only use dynamic when I need to make API endpoints that HAS to talk to external things where I do not have the details on the Contract, the external thing asks for things I do not have, so I make a map and deliver the answer it requests, but it is very rare. Payment Gateways tend to be such use cases more often than not. 😞
I had never used dynamic for anything until i tried using a charting package. my Mata was stored in a dictionary and the package required a pre defined class. Luckily there was a solution using an expandoobject. That seemed to be a better solution than copying fields around
It was created in a time when C# was used to interface with COM and MS Office automation. A time, when "objects" were "remote" and changed their properties and classes villy nilly left and right at runtime.
I used once dynamic where I serialize an object (with some optional properties) into JSON and send it to the customer server. Otherwise I always use proper classes.
I believe I have identified three patterns where I have been forced to rely on dynamic because I have been unable to find a different solution because C# is really lacking in the generics department. The first is dynamically calling the correct overload. I have N overloads of a method, and I have to call the right one. The arguments that differs between these overloads is a parameter of a generic type T. I have to look it up at runtime to call the right overload. Maybe a different approach could have been used here to reduce the amount of overloads, though. But that would break a lot of code. The second is metadata. C# doesn't allow passing metadata objects at compile time unlike e.g. C++. So you can't look up things like types from a type at compile time. It has to be done at runtime and that means dynamic. Maybe it's possible to pass all the required information as type parameters, but that just means so much extra verbosity that it's just not worth it in my opinion. And the third is type constraints. Say I have interfaces IDerived1, IDerived2, IDerived3 that all implement IBase. For generic code purposes, I might have a method that accepts an IBase type. But we need to look up if the type is actually IDerived1, IDerived2 or IDerived3 and handle them separately. The problem is though, that even if we know that our type that implements IBase also implements IDerived1 (through e.g. type checking), we can't call a method that has a IDerived1 constraint. The only solution I know is to mess around with dynamic or reflection to delay the call until runtime. I would love to find solutions that didn't involve the use of dynamic or reflection here, but for right now, I just haven't found solutions to these problems. So I believe dynamic has a place in the language because the C# committee doesn't seem to want to fix the language's generic capabilities.
Perhaps I'm misunderstanding your use-case, but it sounds like what you need in the interfaces scenario is a cast e.g. through pattern matching? void Method(T thing) where T : IBase { if (thing is IDerived1 iDerived1) iDerived1.SomeMethod(); }
@@8ytan One example is that I had some code roughly looking something like this: internal interface IBase { } internal interface IDerived1: IBase { } internal interface IDerived2: IBase { } internal struct Meta { } private void Foo(T Arg) where T: IBase { if (Arg is IDerived1) HandleDerived1((dynamic)new Meta()); else if (Arg is IDerived2) HandleDerived2((dynamic)new Meta()); } private void HandleDerived1(Meta Unused) where T : IDerived1 { } private void HandleDerived2(Meta Unused) where T : IDerived2 { }
@@Sayuri998 I'm still not really seeing the issue. If you have a method that only handles IDerived1, why aren't you just accepting that as the type? private void Foo(IBase Arg) { if (Arg is IDerived1 iDerived1) HandleDerived1(iDerived1); if (Arg is IDerived2 iDerived2) HandleDerived2(iDerived2); } private void HandleDerived1(IDerived1 iDerived1) {} private void HandleDerived2(IDerived2 iDerived2) {} This doesn't need generics at all, and seemingly allows for the same functionality without boxing to a dynamic type or the mess of the unnecessary Meta class. Of course, if you're going to use pattern matching like this you should probably use a switch instead of ifs, but that's more of a code quality issue than an implementation difference.
In .NET since 1.0. I have had to use dynamic a handful of times (3 maybe) but most of my work involves interfacing C# with a loosely typed enterprise language. Performance is really never an issue vs simplifying that interfacing with the other language and its artifacts. It is a great tool to have in the rare cases where needed. I will take the flexibility over performance any day.
I have found 2 handy use cases for dynamic until now. 1/ When you want to add SOAP or HTTP header to a WCF client handed to you, but you do not know the exact interface at compile time. public TResult CallWithDataServiceMode(TClient client, Func func) where TClient : ICommunicationObject { IClientChannel channel = ((dynamic) client).InnerChannel; using (new OperationContextScope(channel)) { // add header 2/ When you want to implement the visitor pattern specific for any (even future) implementations. In classic implementation, you would have to know all possible inheritors beforehand. public interface IClasicVisitor { public void Visit (Shape o); public void Visit (Dot o); public void Visit (Circle o); } public interface IDynamicVisitor { public void Visit (Shape o); } public interface IGraphic { public void Draw (); public void Accept (IClasicVisitor v); public void Accept (IDynamicVisitor v); } public class Shape : IGraphic { ... } public class Dot : Shape { ... } public class Circle : Shape { ... } public class DynamicVisitorImpl : IDynamicVisitor { public void Visit (Shape o) { dynamic item = o; System.Console.Write ($"Visited {o.GetTypeName()}, Calling Draw"); item.Draw (); } }
I have used the Dynamic type for web services that return user-specified subsets of fields and for SQL generators that do not know the state of the table at runtime. Doing these things without Dynamic would not be a fun time.
I used dynamic when I had a Dictionary to map a string or enum to an expression-tree of a SQL order by function. So something like this: new Dictionary { { "hired", (Expression)(x => x.DateHired) }, { "name", (Expression)(x => x.Name) }, { "age", (Expression)(x => x.Age) } }; I don't see a way to do this neatly without dynamic but I'm curious if you do.
It looks like Expression has a non-generic abstract base so presumably you could store , the documentation only shows Compile and Update as being on the generic class so if you need those you'd still need a way to convert to the right generic template or to use dynamic.
@@Vaelosh466 I don't need Compile or Update but I need to give the object to the Queryable.OrderBy() method which only accepts the concrete generic type. By using dynamic C# allows me to compile the code and trust that the dynamic type at runtime actually turns out to be the correct Expression type.
What about using dynamic variable for when you want to use an undefined object(anonymous) in a method: private void DMethod(dynamic textBox) { textBox.Clear(); //Other code } And then use it for your multiple textboxes without having to write the same code if it was for each one of the textboxes. How bad is it going to be ;?
I'd still use reflection instead of dynamic, BUT I would instead use reflection + expressions to compile at runtime a custom accessor, which should be faster than all the other methods (except for just directly calling, ofc)
I think dynamic is missing a key feature: duck typing (like being able to cast a dynamic object into an ISomething, even if it doesn't explicitly implements ISomething, as long as it has compatible members). I'm not saying that would make dynamic something to use carelessly, but in some rare cases, it could be quite handy.
I almost never use Dynamic in my codes except when I want to test an API which I have so little documentation of. In those cases dynamic is very useful to explore and play around.
In my experience, I avoid using dynamic at all costs. If the API I want to connect to is not "documented", I prefer to extract the JSON, put it in a place that converts it to a c# class, and create an abstraction that from that API returns my models. Now, if the API I want to connect to is a netcore library that just returns dynamic or object, I'd wonder why we're using that in the first place.
Congratulations for the video Nick, great content as always. I have a question... does it make any sense to use dynamic DTOs for integration testing (and avoid using the production DTOs) ? I personally follow this approach so that in case a rename is done on a production DTO attribute, this would lead to a test failure. I guess another way to secure that is by replicating the DTO classes in the test projects, but I have adopted dynamic types as I believe they better simulate the way an API consumer would compose an HTTP request body. Would like your opinion on this one 😄
I will actually stay away from dynamic going forward unless its something testing related and it simplifies the problem. Didn't realize the performance aspect was that bad. I have used it in the past for reading dynamic data from the database and just returning it up the stack not caring about the actual structure, aka reporting being the scenario.
There is an entire infrastructure around this. ExpandObject is less memory efficient since it is a bag of data created at runtime. Btw. ExpandObject implements this key interface which allows for the expando-capabilities and more: System.Dynamic.IDynamicMetaObjectProvider
In my experience writting DSL's, dynamic tends to be generaly slower than normal calls, but waaaaaaay faster than reflection calls, the initial usage is very slow (because the way it works emitting runtime code)
@@h3ftymouse Yes, I do not disagree, but I believe not exactly. One of the biggest uses of dynamic in my DSL's was due to the impossibility of creating an efficient wrapper around all C# operator overloads, making it practically impossible to interoperate directly with CLR objects without creating wrappers or non-exhaustive type checking, currently however we have the operator interfaces (in the most recent versions), so their use for this purpose also becomes obsolete, I could simply use them instead of resorting to dynamic.
Dynamic is good for some configs or files parsing if you for some reason don't want to write dto - so if you would use dictionary anyway, then it is good.
The only reason i use dynamic objects was... When i wanted to test private functions. I now have a different approach for that, but given the performance shown here i may think about it twice. In fact, i am pretty sure dynamic was added for occasional VB programmers as a replacement for Variant dara type.
Having to refactor code that heavily (and completely unnecessarily) relies on dynamic is an absolute nightmare. Type safety goes straight out the window, and you can wave goodbye to IntelliSense, because how is it to know if the input is going to be an integer, a float, a car, or a .NET Framework 3.5 WCF service handler? And if the input types are logically related, but this isn't reflected in the code, you then have to go back and implement some sort of polymorphism on top of those types. Please, people, unless you absolutely and irrefutably have to use dynamic, just don't...
just changed our code base... not using dynamic anymore, not cuz I think it's bad only cuz I just realized that I have a way around and don't need to use it
I've only ever used dynamic once and that was for an interop scenario where it dramatically simplified the implementation. In general, I don't like it.
Honestly it’s so niche that it should probably be removed or at least disabled by configuration (disabled by default) Typescript allows for this with no-explicit-any linting option
The only time I've ever used dynamic was when I had to integrate with a pretty poor API. I've nothing against it in principle but frankly have no use for it.
Me: "Hey, returning dynamic object from sql might be easy. Gonna do research." Nick: "...You should be not be using it." Me: "Well better not use it.."
I'm tempted to convert my code to use dynamic due to cleaner code and possible performance gains. I'll have to benchmark the code to confirm this of course.
I regularly watch your videos and will be honest that most of industry projects (like 80% or more) that are done dont need this small performances that you mention so using dynamic I think is ok (example simplify reflection code or you mention calling some dynamic language code etc). But its good to know the penalties that you get when using it (nice video)
I've seen dynamic used in one project in all my life and in that case the dev "didn't think of"(his words) interfaces or generics or that all types can be converted to objects.
dynamic came through a PR today at work, and I was like, WTF, why would I approve this. He did justify why our legacy code base has this mess, but I am still not a fan of the keyword, especially for API calls.
I never used dynamic before and dont plan to and i can´t see any use-case for that. Also i fully agree with you, its ugly and will lead to bad code due to the fact, that no compile time validation can be done.
Anyone else think it seems a bit odd for Nick to claim Dynamic performance isn't really that bad after he's given us micro-benchmarks showing off the minuscule differences in iteration speed (not overall loop performance, just the iteration alone) for different techniques of iterating an array or List? 🤣
Please upload more videos that are not performance-related. For most people, thinking about performance at this level is not so helpful. As you mentioned, there are many reasons not to use `dynamic` in C#, or dynamically typed languages, but performance isn't high on that list
I'm now planning on using dynamic in automated UI tests. Some UI elements are defined based on runtime information. These will be accessible in tests as dynamic properties, like staticly defined elements (as opposed to GetDynamicElement("name") ) to beautify the testing interface. The performance shouldn't matter - UI testing steps take very long anyway.
I'd be interested to see how this works with operators performance-wise. A common use case I find that people leverage dynamic for is older versions of C# (i.e. pre-generic math) when they wish to, for example, add two enum members together using only generic type constraints (where T : struct, Enum). There's a multitude of ways one could use (assume integer and cast - doesn't work if the enum is 'ulong' for example; use cached reflection to retrieve the correct add method; emit and cache IL; and, for a lot of people the easiest, use dynamic).
I use dynamic only in the form of ViewBag that is in Web Applications. It mades communication between server and client easier. I mainly use it for giving a title to webpage dynamically.
In 20 years of writing C# code I've never once used dynamic. If anything, this video showed me that the performance of dynamic is way better than I would have guessed. I don't see myself starting to use it though - it's just not the right solution to the kinds of problems I need to solve in C#. Unless I decide to host IronPython in an app, which it turns out, I just might for a current project - that's what dynamic was made for and is likely the only thing I would ever use it for.
I use dynamic extensively in unit tests. It really helps in truly doing test-first as it will compile fine as a dynamic and explode during the test causing it to be red. It's a minor thing, but I've really come to love the flow. That and dynamic language integration as you mentioned are the only places I've ever used it.
How you mapping complex queries to data model? I always return my complex queries to IEnumerable because it's too complicated to mapping such queries to data model
I'm surprised you didn't mention the reading and writing of JSON and using dynamic. I like it as JSON and versioning isn't a real thing without schemas. I read what is provided, and use a string,dynamic dictionary to hold the key value pair.
I use it mostly when endpoint http response with json does not have strict structure and may vary from request to request, for other situations I prefer to create definition for response explicitly.
When endpoint return result vary from request to request it looks like very bad design from endpoint creators.
@@F4C31355 Of course. But sometimes you can do nothing here
I've used dynamic in a couple of scenarios moderately recently. The first (and main one) was when I was working with an Excel add-in that had to work on multiple versions of Excel, but with PIAs that effectively became incompatible across versions based on the COM object returned from Excel. Complex solution probably involved two DLLs in different domains (when was the last time you needed to use global:: before a namespace def?). That would have been horrible and it was a relative edge case so dynamic + try/catch/notify worked.
The second was in a set of helper methods for working with reflection. Using dynamic in an unusual scenario enabled me to avoid numerous headaches around mapping types correctly for the general case. Basically it was acting like Object but in a scenario where the called method took or returned a strict (but unknown and unspecifiable, typically because of accessibility specifiers) type. Passing around a dynamic meant that known methods could be called even if they had an internally typed parameter.
Sometimes you don't have much choice and you're working with truly dynamic data that you have to represent somehow, either as a Dictionary or some other means e.g. a tagged data structure. I've just worked on a system that has an API taking in a tagged structure i.e. a type that has a Type member and a Data member. This API has no idea what it will be working with, it's function is to take this data and store the JSON string in the database and also retrieve it from the database and at some point the program will have the dynamic data serialized into a known type. I once wrote a small 2D game engine in C++ and it had a Lua scripting interface that exposed some of the C++ classes. The Lua primitives had to be converted into C++ primitives at runtime, the data was pushed onto a shared stack whereby Lua function calls push their args onto this stack when calling into the C++ functions and C++ pushes back any return values back to Lua. Sometimes data is in a raw format, it's just bytes and that's all you know about it at the time. Usually the data goes through some pipeline that converts the data into known types but there is an intermediary stage where you have truly dynamic runtime data and it has to be represented somehow be it a 'dynamic' object or a simple void* and size_t. If you interface with other language runtimes, you will inevitably have to convert the primitive or user types between these runtimes, but there's not many other legitimate reasons to be using dynamic. If you can possibly know the type at compile time (even if you have to use some nullable fields) it's far better than having runtime known only values.
I've seen codebase where the guy who wrote it used ExpandoObject everywhere. It was nightmare, I can't unsee it.
I had a situation where I wanted to write a Visitor pattern implementation for a graph of entities which I could not control. So I couldn't add .Visit() methods to each entity, to call back in to the visitor.Accept() methods with complete type information. So what I ended up with was using dynamic: "((dynamic)visitor).Accept((dynamic)entity)". The first dynamic told the compiler to choose and bind the .Accept() method override at runtime, and the second dynamic told the compiler to use the runtime type of the entity object as the argument. It worked like a charm and the performance wasn't even too bad. Unfortunately sonarqube complained about all those .Accept() methods apparently being unreferenced (even though they were all covered by unit tests, so they were clearly getting called!). I'm not recommending this strategy to anybody else, just pointing out that dynamic has some uses when other methods of solving problems fail because of lack of compile-time type info.
I think it would be cool if C# added a feature that allowed use of ExpandoObject and similar things *without the dynamic keyword*. Because dynamic delegates all the binding to runtime, but in the case of ExpandoObject, it should be possible to bind all property access to method calls on IDynamicMetaObjectProvider, at compile-time.
I remember I used dynamic once as a method parameter to access a property on multiple types that had the same type and name, I assume I couldn't change the objects I was dealing with to implement an interface.
The only time that I needed to use dynamic type in C# was interoperability calls to an application written in VB6. I use reflection when calling C# objects that I don't know the type of the caller.
In my case I was using ExpandoObjects in a solution which needed to retrieve multiple .CSV files where each one of them could have a different header (20/30 header possibilities). I used CSVHelper to map the needed properties with the help of a dictionary to determine the type of header then created an object with some properties including the header and the csv values as a json.
Then, when needed to display the multiples .CSV lines objects in a graphical interface with Blazor, because I wanted to use the same component for each possible .CSV type, I've made the decision when retrieving the object from the database to instanciate the json as an ExpandoObject. Because the ExpandoObject was mainly for Reading purposes I didn't need to know it's properties in advance. I've also made dynamic search fields based on this ExpandoObject and it work's perfectly.
Anyway, I'm not sure if I would be able to do something more cleaner and maintenable for my company if I used a lot of conditions in order to achieve the same result.
I use dynamic with numerics. Before INumeric, if you had two numeric types, you couldn't easily multiply or add without it. It's still not that easy because if you have two different numeric types like int vs double, multiplying them when their type is known is easy, but if their type is unknown, dynamic is the only way still (I'm aware of).
I've found exactly only one application of dynamic in all my codebase, but it is really very efficient. I am using it in one very low level place where I invoke method over reflection and get result as Task, then I await that task and want to get result if it is generic task and null if not, I just do this ((dynamic) task).Result and it is magically returns result in minimal possible time. This time is comparable to cached reflection and even slightly better, but it needs no caching at all, and I don't want to apply caching in that place, cause it can outcome in caching almost every property and method of every type in whole application. I use reflection cache only in places where diversity of cached types is small and controlled, but in such abstract and hot path in app dynamic does it's best.
A (very niche) use-case I've enjoyed with dynamic is when dealing with direct json, but you're unable/don't want to de-serialize it directly to a type (for whatever reason). If you're looking for a key regardless, and it fails, that'll fail at runtime either way. So doing myJsonObject.MyProperty from a JObject reads a bit better than trying to GetProperty() on everything with Newtonsoft/etc. That being said, that is the only use-case I've found where it didn't feel like I was introducing a complete anti-pattern.
I once had a project where I had a "compiler" that would read reflection info, and based on that info, emit IL code for dynamic invokation of methodinfo, and cache that code to a delegate. To my surprise, the results of benchmarks (just the calls, not the emmitting part) showed that the call speed was almost as fast as a regular delegate call! I basically had found a way to create more efficient dynamic calls to methodinfo.
I am so sad that I lost the project (not in cloud, not in my comp, nowhere). But I can rewrite it again sometime.
I only ever had to use Dynamic in one case in my previous job and that was to call a badly written php endpoint where in some cases it would return an array of something and in some cases it would return an object of something else. So instead of writing truly complicated code to read the result I just used the dynamic to parse it from json and then move by mapping it into an appropriate poco object. I was making an adapter between that endpoint and Dynamics CRM back then.
Nick can you do a video on Func keyword and when I can make use of it in a real life scenario.
I don't use dynamic, but my codebase has a lot of places where I dynamically call methods. I try to cache them into delegates but there are places where I need to create an object array to invoke the methods. I'll look into using dynamic for this case.
you could instead use expressions to generate a method invoker and compile it at runtime. It would be strongly typed, so after caching it the invocation would be alloc-free and most likely faster than any other method of dynamic access
Interesting video. Currently I'm using dynamic to operate with SharePoint lists through Microsoft graph since people can just keep adding or removing columns to those and I always need to get all data available.
I only use dynamic when I need to make API endpoints that HAS to talk to external things where I do not have the details on the Contract, the external thing asks for things I do not have, so I make a map and deliver the answer it requests, but it is very rare.
Payment Gateways tend to be such use cases more often than not. 😞
I had never used dynamic for anything until i tried using a charting package. my Mata was stored in a dictionary and the package required a pre defined class. Luckily there was a solution using an expandoobject. That seemed to be a better solution than copying fields around
It was created in a time when C# was used to interface with COM and MS Office automation. A time, when "objects" were "remote" and changed their properties and classes villy nilly left and right at runtime.
I used once dynamic where I serialize an object (with some optional properties) into JSON and send it to the customer server. Otherwise I always use proper classes.
I believe I have identified three patterns where I have been forced to rely on dynamic because I have been unable to find a different solution because C# is really lacking in the generics department.
The first is dynamically calling the correct overload. I have N overloads of a method, and I have to call the right one. The arguments that differs between these overloads is a parameter of a generic type T. I have to look it up at runtime to call the right overload. Maybe a different approach could have been used here to reduce the amount of overloads, though. But that would break a lot of code.
The second is metadata. C# doesn't allow passing metadata objects at compile time unlike e.g. C++. So you can't look up things like types from a type at compile time. It has to be done at runtime and that means dynamic. Maybe it's possible to pass all the required information as type parameters, but that just means so much extra verbosity that it's just not worth it in my opinion.
And the third is type constraints. Say I have interfaces IDerived1, IDerived2, IDerived3 that all implement IBase. For generic code purposes, I might have a method that accepts an IBase type. But we need to look up if the type is actually IDerived1, IDerived2 or IDerived3 and handle them separately. The problem is though, that even if we know that our type that implements IBase also implements IDerived1 (through e.g. type checking), we can't call a method that has a IDerived1 constraint. The only solution I know is to mess around with dynamic or reflection to delay the call until runtime.
I would love to find solutions that didn't involve the use of dynamic or reflection here, but for right now, I just haven't found solutions to these problems. So I believe dynamic has a place in the language because the C# committee doesn't seem to want to fix the language's generic capabilities.
Perhaps I'm misunderstanding your use-case, but it sounds like what you need in the interfaces scenario is a cast e.g. through pattern matching?
void Method(T thing) where T : IBase
{
if (thing is IDerived1 iDerived1)
iDerived1.SomeMethod();
}
@@8ytan One example is that I had some code roughly looking something like this:
internal interface IBase { }
internal interface IDerived1: IBase { }
internal interface IDerived2: IBase { }
internal struct Meta { }
private void Foo(T Arg) where T: IBase
{
if (Arg is IDerived1)
HandleDerived1((dynamic)new Meta());
else if (Arg is IDerived2)
HandleDerived2((dynamic)new Meta());
}
private void HandleDerived1(Meta Unused) where T : IDerived1 { }
private void HandleDerived2(Meta Unused) where T : IDerived2 { }
@@Sayuri998 Why are your using generics to pass in IBase to you methods instead of just passing it in as an IBase type?
@@realtimberstalker Because the exact type matters. This comes back to the fact that C# doesn't support metadata types at compile time.
@@Sayuri998 I'm still not really seeing the issue. If you have a method that only handles IDerived1, why aren't you just accepting that as the type?
private void Foo(IBase Arg)
{
if (Arg is IDerived1 iDerived1)
HandleDerived1(iDerived1);
if (Arg is IDerived2 iDerived2)
HandleDerived2(iDerived2);
}
private void HandleDerived1(IDerived1 iDerived1) {}
private void HandleDerived2(IDerived2 iDerived2) {}
This doesn't need generics at all, and seemingly allows for the same functionality without boxing to a dynamic type or the mess of the unnecessary Meta class.
Of course, if you're going to use pattern matching like this you should probably use a switch instead of ifs, but that's more of a code quality issue than an implementation difference.
In .NET since 1.0. I have had to use dynamic a handful of times (3 maybe) but most of my work involves interfacing C# with a loosely typed enterprise language. Performance is really never an issue vs simplifying that interfacing with the other language and its artifacts. It is a great tool to have in the rare cases where needed. I will take the flexibility over performance any day.
Dynamic has only been around since version 4 of .NET.
I have found 2 handy use cases for dynamic until now.
1/ When you want to add SOAP or HTTP header to a WCF client handed to you, but you do not know the exact interface at compile time.
public TResult CallWithDataServiceMode(TClient client, Func func) where TClient : ICommunicationObject
{
IClientChannel channel = ((dynamic) client).InnerChannel;
using (new OperationContextScope(channel))
{
// add header
2/ When you want to implement the visitor pattern specific for any (even future) implementations. In classic implementation, you would have to know all possible inheritors beforehand.
public interface IClasicVisitor {
public void Visit (Shape o);
public void Visit (Dot o);
public void Visit (Circle o);
}
public interface IDynamicVisitor {
public void Visit (Shape o);
}
public interface IGraphic {
public void Draw ();
public void Accept (IClasicVisitor v);
public void Accept (IDynamicVisitor v);
}
public class Shape : IGraphic {
...
}
public class Dot : Shape {
...
}
public class Circle : Shape {
...
}
public class DynamicVisitorImpl : IDynamicVisitor {
public void Visit (Shape o) {
dynamic item = o;
System.Console.Write ($"Visited {o.GetTypeName()}, Calling Draw");
item.Draw ();
}
}
I have used the Dynamic type for web services that return user-specified subsets of fields and for SQL generators that do not know the state of the table at runtime.
Doing these things without Dynamic would not be a fun time.
I used dynamic when I had a Dictionary to map a string or enum to an expression-tree of a SQL order by function. So something like this:
new Dictionary
{
{ "hired", (Expression)(x => x.DateHired) },
{ "name", (Expression)(x => x.Name) },
{ "age", (Expression)(x => x.Age) }
};
I don't see a way to do this neatly without dynamic but I'm curious if you do.
It looks like Expression has a non-generic abstract base so presumably you could store , the documentation only shows Compile and Update as being on the generic class so if you need those you'd still need a way to convert to the right generic template or to use dynamic.
@@Vaelosh466 I don't need Compile or Update but I need to give the object to the Queryable.OrderBy() method which only accepts the concrete generic type. By using dynamic C# allows me to compile the code and trust that the dynamic type at runtime actually turns out to be the correct Expression type.
What about using dynamic variable for when you want to use an undefined object(anonymous) in a method:
private void DMethod(dynamic textBox)
{
textBox.Clear();
//Other code
}
And then use it for your multiple textboxes without having to write the same code if it was for each one of the textboxes.
How bad is it going to be ;?
I'd still use reflection instead of dynamic, BUT I would instead use reflection + expressions to compile at runtime a custom accessor, which should be faster than all the other methods (except for just directly calling, ofc)
I've seen it being used in places where simple 'object' would be sufficient. Ugh, i still have nightmares to this very day.
I think dynamic is missing a key feature: duck typing (like being able to cast a dynamic object into an ISomething, even if it doesn't explicitly implements ISomething, as long as it has compatible members). I'm not saying that would make dynamic something to use carelessly, but in some rare cases, it could be quite handy.
You can sort of do this with a library like Clay or ImpromptuInterface
I almost never use Dynamic in my codes except when I want to test an API which I have so little documentation of. In those cases dynamic is very useful to explore and play around.
How did you use dynamic if you did know little about api (classes, properties)? Did you just guess their names?
@@magashkinson mostly when I have information about method names and parameters but no documentation of return types etc.
In my experience, I avoid using dynamic at all costs. If the API I want to connect to is not "documented", I prefer to extract the JSON, put it in a place that converts it to a c# class, and create an abstraction that from that API returns my models. Now, if the API I want to connect to is a netcore library that just returns dynamic or object, I'd wonder why we're using that in the first place.
how can i handling wave files in c#, change frequency and more. thanks
Most recently i've used expando object for serialization where I don't feel like creating another class just for this purpose
Congratulations for the video Nick, great content as always. I have a question... does it make any sense to use dynamic DTOs for integration testing (and avoid using the production DTOs) ? I personally follow this approach so that in case a rename is done on a production DTO attribute, this would lead to a test failure. I guess another way to secure that is by replicating the DTO classes in the test projects, but I have adopted dynamic types as I believe they better simulate the way an API consumer would compose an HTTP request body.
Would like your opinion on this one 😄
I will actually stay away from dynamic going forward unless its something testing related and it simplifies the problem. Didn't realize the performance aspect was that bad. I have used it in the past for reading dynamic data from the database and just returning it up the stack not caring about the actual structure, aka reporting being the scenario.
For the last example and reflection: how about line expression compilation?
There is an entire infrastructure around this. ExpandObject is less memory efficient since it is a bag of data created at runtime.
Btw. ExpandObject implements this key interface which allows for the expando-capabilities and more: System.Dynamic.IDynamicMetaObjectProvider
In my experience writting DSL's, dynamic tends to be generaly slower than normal calls, but waaaaaaay faster than reflection calls, the initial usage is very slow (because the way it works emitting runtime code)
Source generators probably obsolete both to a degree
@@h3ftymouse
Yes, I do not disagree, but I believe not exactly. One of the biggest uses of dynamic in my DSL's was due to the impossibility of creating an efficient wrapper around all C# operator overloads, making it practically impossible to interoperate directly with CLR objects without creating wrappers or non-exhaustive type checking, currently however we have the operator interfaces (in the most recent versions), so their use for this purpose also becomes obsolete, I could simply use them instead of resorting to dynamic.
@@diadetediotedio6918 I see, thanks for clarifying
I use dynamic in some unit tests ! For complex instance types that are casted dynamically
As long as that doesn't transfer over to benchmarks.
Dynamic is good for some configs or files parsing if you for some reason don't want to write dto - so if you would use dictionary anyway, then it is good.
Some time ago I happened to encounter a COM API that was returning dynamics... it wasn't fun to work with
The only reason i use dynamic objects was... When i wanted to test private functions. I now have a different approach for that, but given the performance shown here i may think about it twice.
In fact, i am pretty sure dynamic was added for occasional VB programmers as a replacement for Variant dara type.
It's made for interop with old COM APIs and dynamically typed languages or script languages.
Having to refactor code that heavily (and completely unnecessarily) relies on dynamic is an absolute nightmare.
Type safety goes straight out the window, and you can wave goodbye to IntelliSense, because how is it to know if the input is going to be an integer, a float, a car, or a .NET Framework 3.5 WCF service handler? And if the input types are logically related, but this isn't reflected in the code, you then have to go back and implement some sort of polymorphism on top of those types.
Please, people, unless you absolutely and irrefutably have to use dynamic, just don't...
just changed our code base... not using dynamic anymore, not cuz I think it's bad only cuz I just realized that I have a way around and don't need to use it
Dynamic is interesting because it supports full double dispatch, which makes certain things much easier.
I've used dynamic for VSTO back then but never looked back.
I've only ever used dynamic once and that was for an interop scenario where it dramatically simplified the implementation. In general, I don't like it.
I use dynamic instead of reflection where possible. It might be very helpful sometimes
Honestly it’s so niche that it should probably be removed or at least disabled by configuration (disabled by default)
Typescript allows for this with no-explicit-any linting option
Dynamic might be slow but my comments are fast
That means your comments are not dynamic 🤣🤪
The only time I've ever used dynamic was when I had to integrate with a pretty poor API. I've nothing against it in principle but frankly have no use for it.
I like using dynamic when writing scripting languages within c#
Me: "Hey, returning dynamic object from sql might be easy. Gonna do research."
Nick: "...You should be not be using it."
Me: "Well better not use it.."
I'm tempted to convert my code to use dynamic due to cleaner code and possible performance gains. I'll have to benchmark the code to confirm this of course.
I regularly watch your videos and will be honest that most of industry projects (like 80% or more) that are done dont need this small performances that you mention so using dynamic I think is ok (example simplify reflection code or you mention calling some dynamic language code etc).
But its good to know the penalties that you get when using it (nice video)
I've seen dynamic used in one project in all my life and in that case the dev "didn't think of"(his words) interfaces or generics or that all types can be converted to objects.
@@sealsharp if he used wrong then he used a tool for the wrong job :)
dynamic came through a PR today at work, and I was like, WTF, why would I approve this. He did justify why our legacy code base has this mess, but I am still not a fan of the keyword, especially for API calls.
Dynamic is for one thing and one thing only and that's a COM interop library
I never used dynamic before and dont plan to and i can´t see any use-case for that. Also i fully agree with you, its ugly and will lead to bad code due to the fact, that no compile time validation can be done.
Anyone else think it seems a bit odd for Nick to claim Dynamic performance isn't really that bad after he's given us micro-benchmarks showing off the minuscule differences in iteration speed (not overall loop performance, just the iteration alone) for different techniques of iterating an array or List? 🤣
If you are considering using dynamic you are already way outside the "performant code" league. Performance and my videos on it, are always contextual
I avoid using dynamic, mainly they should not be used on code without any interoperability with script languages etc
I dare you to show this to a Python/Js developer
See dynamyc for the first time here and can't find a reason to use it
Please upload more videos that are not performance-related. For most people, thinking about performance at this level is not so helpful. As you mentioned, there are many reasons not to use `dynamic` in C#, or dynamically typed languages, but performance isn't high on that list
I hate dynamic and ExpandoObject with a passion ! I let the compiler deal with types. I'm too old for that BS !
It's very slow on load up...
@@mythbuster6126 is it less AOT frienly than reflection?
@@iGexogen It's dynamic code generation, so yes.
dynamic is like goto. You should avoid it in 99% of cases, but it's handy to have it around for the remaining 1%
C# needs discriminated unions to defend against this evil so badly.
One could of call MethodInfo.CreateDelegate() once, and then just invoke the delegate, this would the best shot for Reflection.