My favourite feature with .Net and C# is that it's a static programming language. This is also the largest problem I have with .Net 5 - As in, its blessing also becomes its curse. Simply because sometime I need a bit more "dynamic nature" than that which .Net provides out of the box. However, .Net 5 has a lot of interesting features, allowing you to circumvent this, opening it up for a more "dynamic nature". Let me illustrate with an example C# HTTP API controller.

x

[Route("magic")]

public class EndpointController : ControllerBase

{

    [HttpGet]

    [Route("{*url}")]

    public async Task<ActionResult> Get(string url)

    {

        /* Do interesting stuff with URL here */

    }

}

Notice the [Route("{*url}")] parts in the above code? This tiny little detail implies that everything going towards "magic/xxx" will be resolved by the controller, and its "xxx" parts will end up becoming the url argument to our method.

Most apps have commonalities that can be extracted, where generalised solutions can be created, based upon patterns of reusable components. Some examples here are Angular Material, BouncyCastle, and MimeKit. All of the previously mentioned libraries assumes you want to achieve something specific, for then to create high level components, allowing you to solve your problems. This of course is the very foundation of "libraries", "frameworks" and "components". As in; Reusability is king. However, the same is also true for your resulting end app. If you look at your last application, you will find that it has at least some of the following moving parts.

• It needs to authenticate users
• It needs to authorise access to its parts
• It needs to log events
• Etc, etc, etc

The AOP promise

The promise of Aspect Oriented Programming was that instead of "coding" these generalised parts, you could "apply them as aspects" to your code. Such as the following illustrates.