DEV Community: Anthony

Why you shouldn’t use the Dynamic type in .NET

Anthony — Fri, 27 May 2022 07:15:01 +0000

Introduction

If you’re an enthusiast like myself, you will get excited when Microsoft release some sort of updates on the language, new libraries or any documentation on what is the new fancy way of doing ‘This’.

Microsoft target those releases to respond and enhance our development experience, thus each feature is the answer to a specific problem in our code. But as times goes by, new developers may question the relevance of some of these additions, and ultimately have a stand with or against them. So, is Dynamic and ExpandoObject obsolete already? Should we use them?

Why Rant :)

The idea for this article came from a PR I was recently checking, I saw my colleague using Dynamic and ExpandoObject… (Sorry R**** !)

What is Dynamic

Briefly, the usage of dynamic tell the compiler to skip all checks like syntaxes and evaluate them on runtime instead:

dynamic test=new object();
test.Bark();

This code will compile normally, even though we know that object does not contain a Bark() function. This error will be shown on runtime instead.

The Problem

Just like the Async keyword, when you start using dynamic, you can’t stop. Your dynamic code will expand just like a virus and bubble up everywhere, removing one of the most underrated benefits of C# which is static types and compile-time checking…

In a way, you will start writing Python or JS in your C# code. If you really want to do that, use that other language from the beginning !

Next, Readability: You’re using an object that you cannot track with your IDE, how can you express your intent with the code you’re writing if even the compiler will skip understanding it. Even C# does not understand what you’re writing and will evaluate it on the fly so how should we ;)

As it wasn’t enough, Performance: The building and compilation phase saves a lot of time ahead of execution. This is the main difference between compiled and interpreted languages…
Each one has his pros and cons but in a cloud environment when you want to squeeze every bit of performance from your app, you should also consider that.

Last but certainly not least, think about your bug hunting journeys, when a newcomer changes anything in the objects or functions. Do you really feel safe while using this feature?
Even if you have unit tests, doesn’t accepting each and every possible value in your algorithm scare you?
Well it should !

The Exception

If this is the case, Why did Microsoft introduce it back in 2010 ?! As discussed before each feature belong to a specific context and solve a problem. So back in the time, C# was Windows exclusive. If you remember .NET Framework (Time flies…), it was a direct competitor to java and other languages.

With the dynamic type feature, Microsoft wanted to achieve something called COM Interop. The idea was that you can integrate and run diverse applications and platforms inside C# and .NET. This was good for integrating with existing systems and scripts into your codebase.

A practical example would be that you have an existing Ruby app and you started using C# for a Desktop App. You can install a library called IronRuby and load your Ruby code INSIDE C#. So if you created a class in Ruby, you can instantiate and use it in your .NET App, which was insane !

This feature was actually made for this purpose. Nowadays with our new and portable .NET. We don’t find this very relevant most of the time and is considered a niche feature.

An Actual Exception

But there’s only a small practical scenario where I still use them… Navigating a complex JSON object. Honestly this is arguably the only context where I see this fitting even.

How to not use it

I am a huge fan of static types and compile time checking. So if I can remove dynamics and even boxing types I would find that ideal.

So as a general rule and conclusion:

Try to use generics, if that doesn’t work:
Try to use objects and boxing, if and only if it doesn’t work:
Your only resort is now the Dynamic type and ExpandoObject :)

But hey, at least you tried !

Why you shouldn't use the Repository pattern in .NET

Anthony — Sun, 22 May 2022 08:55:25 +0000

Introduction

So you’re writing code using .NET, and you surely follow the Clean Architecture and its layered abstractions. Apparently and even though the concept was introduced long ago, this is getting very trendy now.

One of your arguments may be that you want your infrastructure to be entirely swappable, you want your application and core business logic to be independent from the database you are using right? The idea is not wrong, as they are hundreds of application relying on this concept. So what is the problem?

Designing an application

Applications are needed to solve a business need. When you design an app, you want it to fill a business and domain gap. Every app stores its data somewhere right?

So you have to carefully choose your infrastructure that corresponds to your application. Let’s say you’re choosing which database to use, how do you generally make the choice?

From my biased and opinionated experience, this choice comes from one of the following criteria's:

Your team is already using SQL Server in this other project, so you will most likely start with it. Install Entity Framework, build your context and you’re done. It can be any provider really..
You’re tied to the technology stack of the company you are in and you can’t just do as you please.
You’re tied by the on premises or cloud constraints of your app (Pricing for example).
Or you actually have this freedom to choose your most optimal database, isn’t that great?

It surely is, but let’s think this through… To persist your business domain, you will start to think on the ‘How should I store my entities’. This will also vary depending on the database you are using:
If you’re using SQL, you will start drawing links and relations to navigate your fixed tables.
If you’re using DynamoDB or Cosmos, you will think about your partition and sort keys, how the entities should be grouped and distributed.
If you’re using MongoDB or anything else really, you will find yourself between the two.

My point is, even though there is a lot of database providers, your plan to concept your database may vary a lot depending on the infrastructure you are using. And yes your domain should not worry about those changes so let’s abstract it. This is when the famous Repository pattern come in handy.

The Problem

You abstracted your famous repository, which contains another abstraction of your database provider (EF Core for example). The benefit? you can swap now the inner abstraction with Dapper… but why would we do that?

The abstraction itself is great, but why do we need to implement it even if it’s not that useful? With that thinking, we should abstract the ILogger interface, or any other module in our system. So that we can ‘swap it when needed’, even when it’s not actually needed…

You’re actually smarter than this, you need to switch from SQL to Cosmos for a cloud migration on Azure. So this is actually very handy right? Well not really:

The repository interface is a contract that the application is using and cannot be changed. If it changes than you actually implemented all of this for nothing.
Not changing it is also a problem, even if you’re app is not tied to the persisted entities, storing and optimizing transactions is highly dependent on the provider. You will store, retrieve and perform CRUD actions differently when switching from SQL to Cosmos. And to honor this famous contract that you cannot break, you will find yourself writing a big mud of code to transform and fetch your entities.

Projecting over time and supposing you’re in a Agile environment where iterating and adding functionalities is mandatory, this bug ball of mud will grow to an unmaintainable or manageable code.

The ‘SMART’ solution

A very smart idea will pop up in your head. The app is really slow and need optimization. This bottleneck will guide to write the entire thing from scratch while optimizing and accommodating to a new schema and a new DB provider. Everything ends well you saved the day !

Feedback

You didn’t actually save the day, you waited and built a big ball of mud that created maintainability and performance issues. It most certainly took you double the time to rewrite with all the functionalities you added over time.

Conclusion

Knowing how to abstract your repository is great, but this should not be a standard where you implement everywhere. Most of the DB clients are already an abstraction so why add another layer on the top? If you’re in a Microservices architecture, your bounded context should not be big enough to rewrite it. 1 or 2 entities are involved only.

Also, it is not that you change your provider everyday, you chose or are bound to a provider and when you do change (which you rarely, RARELY do), it is really useful to see what will break and make the most adequate and optimal change for this new source.

DON”T OVERUSE THIS PATTERN FOR THE SAKE OF CLEAN CODE.