Dynamic Anonymous my experience through out assemblies doing unit tests and more RuntimeBinderException Headache

While at work on a project I was facing a matter that caused me a lot of headache, which is passing dynamics throughout assemblies, after doing a lot of research and investigation like

Should I use dynamics if no then why and how can I compensate it’s flexibility and stuff like that  just to get a profound to wither to use it or not ,

And I found that it is preferred not to use dynamic whenever possible and that because

The overhead it causes on the runtime, in other words the time to identify properties types is not done on compile, it is done on runtime thus the overhead.

Nevertheless the fact that literally we do not know if it is working alright, unless we are at runtime if it is not working for instance we got a property name wrong  then boom exception for sure

BUT

a very convenient guy would say where are your tests that should cover that from happening “just for your info not all of us right tests and not all of us right proper tests”, I would say that is one other reason why we should not use dynamic, because most of us faced this problem when creating tests, The problem is
exception run time binder could not find property x in object y,                                  

 first the reason this happens because when create a test for dynamic return you will most likely will use mocking and other stuff all the guys involved in TDD probably know about it to mock the return of a dynamic, but that is not the problem, the problem  is passing dynamic objects throughout assemblies what happens is in testing run time the dynamic properties do not get resolved by the test runner, the reason why this was happening made me go nuts I was spinning round on why in hell is it not working and I got a bit confused to think that it was a bug in VS or something and there is a bug similar to that reported to Microsoft

https://connect.microsoft.com/VisualStudio/feedback/details/597276/dynamic-runtime-fails-to-find-iset-t-contains-during-runtime

and so at first I thought it is a bug and it is reported on this have read a thread about, after long hope I found that me using anonymous type was the reason as they don’t get resolved across assemblies,

So after being in so much trouble I just had to set some rules when using dynamics and that is for the sake of safety and good performance which were:

That you should not use dynamic extensively avoid them whenever possible there are certain situations where you will not be able to completely not use them but at least keep this in mind

You should never pass it through assemblies the reason why this is because, create a concrete class and pass it, that way your tests will not get screwed over a tiny reason like using anonymous.

What drives people towards dynamics and can there be something that can replace it ?

Flexibility the thing about it is that people will always resort to dynamics cause it is easy and removes a lot of headache in configuration or casting, but if something goes wrong, lets say no good deed is left unpunished, you will probably get things missed up.

Another thing is contracts usually when creating Interfaces all you have to put as return of a method is dynamic it does not matter if it was a class instance of your own, a POCO object, a collection of any type of objects or anything this contract will be implemented perfectly.

For the flexibility part I don’t think that can be replaced but for instance the Interface,  it is a very common best practice to put all your interfaces “Contracts” in one single independent  assembly  so you can’t use any custom type or class as a return, that can easly accomplished by dynamics but it can be also done using generics,

The use of the magical <> instead of dynamics if it returns a list use  IList and that should do the trick for you all the way.

Here is a link where I created a generic repository interface

http://mohammedezzatawad.blogspot.com/2011/09/generic-repository-interface-that-can.html

To illustrate this with examples here is:

A sample test would normally fail cause of exception runtime binder exception

 so the test simply check for a return of a function that returns a dynamic object and checks for its return, once run at run time, a binder exception  will be thrown in the Assert statement as the props cannot be resolved

So my solution for this problem was pretty simple, I created a concrete class to return instead of a dynamic so whenever possible I did not have my methods returning dynamics so that way I lost the headache

For Generic Interface I only used generics here are some samples

The generic repository interface

Another one would be as following

The issue would be how to generalize the return of the methods in the interface or contract, I have two situations one is when returning a custom object and the second when returning a collection of customer objects, each one I have demonstrated how to return them in a generic way using IList for collection and The <T>.

That’s it hope it was of a help  to you guys.

Thanks for reading.