NDepend Blog

Improve your .NET code quality with NDepend

The problem with frameworks

October 31, 2024 3 minutes read

The problem with Frameworks
I just watched this short 2:39 video from Uncle Bob, and it rang a bell. His books inspired me two decades ago to create NDepend—a tool for .NET developers who prioritize code structure and quality. Consuming a framework is all about coupling and dependency.

The problem with Frameworks

  • Part of the fashion that happens in our industry are various new frameworks being released. The community get excited about it
  • Framework are not made for your benefits but for framework author’s benefit.
  • There is a huge asymmetry between framework consumers and framework authors:
    • Your code is deeply coupled with the framework .
    • Framework authors don’t care if the framework get in your way at a point, forces you to work around the framework.
  • Usually Frameworks make the first months of a project easy but then they make the following years of the project difficult.
  • Good architects look at a framework with a cost/benefit trade-off in mind.
  • Good architects put boundaries between the framework and the rest of the code.
  • When using a framework you must commit to them, they do not commit to you.

Our .NET journey through Frameworks

.NET is a platform, it is also a framework. We were all once tightly coupled with the .NET Framework, but since 2017, it’s been all about .NET Core. Microsoft made it relatively easy to migrate to .NET Core. However we coupled most of our code with .NET Standard 2.0 (77%). This is essential, as our code runs on both .NET Framework (when used as a Visual Studio extension) and .NET Core (when generating web reports on macOS and Linux).

.NET Core is here to stay. We’re looking forward to the day we can fully transition from .NET Framework. This will let us take advantage of the new features .NET Core brings each year. Possibly we will remain mostly coupled with .NET Standard 2.0 and will abstract the usage of .NET Core goodies.

We went exactly through the way Uncle Bob describe. Initially, we consumed a lot of trendy frameworks an we loved it. Over time, they began to get in our way, making it natural to build abstractions around them. Migrating to .NET Standard 2.0 gave us the opportunity to discard most of these frameworks. We just rewrote the necessary features ourselves our way. We abstracted a significant portion (63%) of the UI from WPF and WinForms to simplify future migration to a multi-platform UI framework.

We kept only the mature, open-source frameworks. The ones that compile mostly or entirely against .NET Standard 2.0 and that don’t require frequent version upgrades. We consider their code as our own since it has become an integral part of our application. When fully migrating to .NET Core, we may fork or contribute to these frameworks to modify certain parts and enhance overall performance.

Conclusion

The trade-off with frameworks is similar to the one regarding code maintainability.

On one hand it can be beneficial to write quick and dirty code and rely on numerous frameworks. This can help for rapid release of an early-stage application and try to meet the market as soon as possible.

On the other hand, over time, untested and poorly written code is like being overly dependent on some frameworks. It becomes an everyday issue, and resources must be allocated to address it. This is the way to move forward and prepare for future challenges.

Let’s end with an interesting comment on the video:

I think lots of people don’t get it due to duality of tech industry and difference in work experiences. Some of us are working in multi-year, large scale projects. Others pour their work into startups, that will cease to exist in a year or two. Those two types of developers have different goals, which influences how they choose technologies and how they approach software architecture.

 

 

Comments:

  1. T.Terlemez says:

    Hello
    You have touched on very important points, thank you.
    Being dependent on frameworks can really cause huge problems in terms of business continuity.
    When Microsoft switched from .Net Framework to .Net Core, we had to move our .Net Framework based web application, which was developed for years in line with the needs of the business, to .Net Core and moving it to another platform required almost the same work, so we had to move the application to PHP.
    The structure of .Net Core, which forced us to revise previously written codes that emerged in each version, was also effective in this decision.

Leave a Reply

Your email address will not be published. Required fields are marked *