Theory of Abstraction

amr swalha — Sun, 29 Jun 2025 14:20:04 +0000

I’ve been building software for years, what I love about it and sometimes hate is that everything keeps changing so fast that a framework can become obsolete and deprecated within two years or even less.

What happens is that a lot of projects don’t want to reinvent the wheel, which makes a lot of sense. They use external libraries and frameworks. These external dependencies are strongly coupled inside the project.

Which makes it hard and sometimes impossible to replace or update. And guess what, these dependencies introduce vulnerabilities and security issues, or sometimes they use an outdated approach and do not follow the latest trends, which makes them no longer optimal to use.

So the more you rely on external dependencies, the more you are likely to have to refactor many parts of your application, or even worse, replace the entire thing. This can be very costly, and not only that, since there is a pandemic of low-quality code and documentation, the process of modernizing your app will be very difficult and hard to do.

So, Mr. Amr, what will we do? How can we do software development and develop software that can run forever? When the aliens come down and they try to run it, it will be as easy as calling an npm script.

There is no simple answer, but there is an approach that I'm adapting currently that we think can mitigate these issues. Although,
Eventually, you will reach a point where you will have to refactor the entire thing; this will make the process easier and even a breeze.

The Theory of Abstraction State:

The more Abstraction you introduce inside your code, the more likely you are to replace and update dependencies inside your code.

No easy way to do this, and the level of abstraction can vary a lot between projects. For example, if you are using Angular and you have one of the well-known
packages such as PrimeNG, where you will use a modal. You can use it directly from the library, but what will you do if you want to update or even replace the entire library?

Using any external dependencies as a very tightly coupled unit inside the code will make it a dependency hard to replace or change. I'm sure the good folks at PrimeNG will maintain the computability as much as possible. But, since technology changes at an insane rate, they have to do a cut-off support at some point, like any project that wants to stay relevant.

I worked on a very large project that used Angular, and when I wanted to update it the version I hit a wall with a package that was used all over the place. And its job was only to display a Model! So, it was difficult to update.

It was very difficult to locate its usage and where to update. Since then, I thought, what if I introduced just a small component that holds any modal library, and instead used it? Then my update was way simpler.

Also, many open-source packages start with a free license and then switch their license, which can lead to many implications. By adding an abstraction layer (I know it's a difficult task) to all or at least the most critical package(s), it can lower the update and change time.

Remember that the framework version is just a number, code never rusts and will not be a big issue to use even .NET 4.5 or Angular 7 to this day, unless there is a critical security issue or you can no longer run the application.

Originally published on my blog

.NET Clean Architecture, Yet Another!

amr swalha — Wed, 14 May 2025 10:35:47 +0000

As you for sure know, there is a lot of .NET Clean Architecture projects, we try to provide a much easier one to use and one that can help developer provide much better results. So, we released .NET Clean Architecture that we worked on for years and used it in multiple projects to help other fellow software developers build better .NET applications.

Backstory

While working at some company, I saw an architecture that layered the application into 4 parts: Core for entities, Infra for general operations, Business for the implementation and the API layer to expose them all.

When looking at them, they really provided a good way to separate the different layers and make the work more reusable. But there was a big problem of boilerplate code for the basic operations.
You had to have on each class GetById and you had to write them for each one, so this was way too boring and redundant for me as a guy who had installed many extensions just to save a few clicks ;)

So, I wanted to make a better solution where you don't have this many codes to write each time and all the basic cruds are already there. So, after some time of trying and testing, I started this project as an internal tool for Advanced Software Solutions and used it in many projects. Now, reached V2.0 I want it to have more exposure and have more people feedback. Also, it was battle tested with a small company, and they liked it a lot so I want more people to take advantage of this.

V1.0

In this version, I had the four layers, Core Operation Business and the API layer. This version was a good start as it shown the ability of the architecture to minimize the need to create any GET operation unless it was very custom, due to the usage of OData. Just add your entity and map it to EF, add a service and an api controller and magic you have all the CRUDs you need created for you. If you want a custom method, you can add it freely to the API or the service.

The feedback was really good, and the usage of this method was really helpful for the developers. But we got feedback that the developers had each time to add a new entity the need to add a service and an API controller. Which became very redundant task in case the application grows bigger. Also, most of the time they just needed the basic CRUD and rarely edited the service or the controller.

V2.0+ (Current Release)

Taking advice from the first release, I looked at the architecture again and decided the following:

Instead of using a service for each entity, and most of the time you don't need a custom code, the Business layer is optional for each entity. If you need more custom code or business logic, you implement an Actor using Akka and then create a partial class for the API controller to use it.
The usage of .NET Source Generator to lower the amount of boilerplate code. Just add your entity and map it to EF and you are all set! The Source Generators will generate the API controller for you, and you will have all the CRUD ready with OData as well.

How to use it

First please go to .NET Clean Architecture and then download the project.

Afterward, you can run the project directly from VS 2022 or just use .NET run cli command (dotnet run) and make sure you install the latest SDK (.NET 9 at the time of writing).

After running the application you will be presented by Scalar

Configuration

In the appsettings.Development.json, you can specify the configuration for the application. The "CleanAppConfiguration" section contains the configuration needed for the application to function correctly. Let's take a look at the section:

"CleanAppConfiguration": {
    "InMemoryCaching": {
      "Enabled": true,
      "Provider": "InMemory",
      "Configs": {
        "Host": "localhost",
        "Port": "11211"
      }
    },
    "Auth": {
      "Authority": "CleanAPI",
      "Audience": "CleanAPI",
      "ValidAudiences": [
        "CleanAPI"
      ],
      "ValidIssuers": [
        "CleanAPI"
      ],
      "Key": "d18bf0b49d5c2679e2250246779570f7a5e79f23"
    },
    "Datastore": {
      "ConnectionString": "Data Source=.;Database=CleanDB;Integrated Security=True;Persist Security Info=False;Pooling=False;Multiple Active Result Sets=False;Connect Timeout=60;Encrypt=False;Trust Server Certificate=True;Command Timeout=0",
      "Provider": "SQLite"
    },
    "ResponseCache": {
      "Enabled": true,
      "Duration": 30,
      "VaryByHeaders": ["Authorization"]
    }
  }

InMemoryCaching
- This to configure the caching for the api and you can enable it or turn it off. You can choose the InMemory or Memcached.
Auth
- To configure the authorization on the API, make sure to change the key and the relevant information.
Datastore
- Where you can configure the datastore, either in memory, SQLite, SQL Server or Postgres. Note that the connection string is required for the SQL server and Postgres.

Note the ResponseCache section is under development.

Adding an Entity

To expose an entity, simply add it inside the CleanBase project inside the Entity folder. After that, make it inherit the EntityRoot class. And you are done! The source generator will generate the API controller for you and hookup the OData to it, so you are good to go!

You can see the generated code for the controller by going to CleanAPI -> Analyzers -> CleanAPIGenerator -> Expand the generator as the image below:

Afterward

We hope you take advantage of this project and architecture, and we welcome your suggestions for this project as we want it to grow better and larger. We want to keep the community version under the MIT license forever.

DEV Community: amr swalha