Following up on the last episode about the Optional type, we continue taking inspiration from functional languages and introduce Either and Error types, as a way to make the possible business logic outcomes more explicit and minimize using exceptions in non-exceptional situations.

In this post, we’ll make use of a concept most commonly associated with functional programming, the Optional type (aka Option or Maybe), in order to make our code safer and more explicit when expressing a lack of value, instead of leaning on the null reference, something that I’m sure has burned us many times in the past.

In this episode, we’ll make things more object oriented, by moving some logic that’s present in the request handlers, which in fact should be present in the domain entities, that currently are just bags of data with public getters and setters.

This past week I had the opportunity to attend Building the Future 2020, an event focused on digital transformation, so I thought about sharing some of the main topics that stuck with me.

In this episode, we’ll take a look at (yet) another approach to organizing data access code, very likely overkill.

In this episode, we’ll take a look at segregating our application use cases in dedicated classes instead of shoving everything into the same service class.

In this episode, we’ll take a look at redesigning an API that has been developed in a traditional layered way, moving to a more interesting onion/hexagonal/ports and adapters architecture (which is apparently very fashionable right now in .NET land).

In C# land, the abuse of services and DTOs is prevalent. How about grouping data and behavior using POCOs? You know, ob)ect oriented stuff 🙂.

“Equals” vs “==” is an old topic, but as it’s often times forgotten, there’s probably no harm in talking about it again.

In this episode, we’ll go through the main changes required to upgrade our currently ASP.NET Core 2.2 applications to ASP.NET Core 3.0.