Since you just purchased a book about design patterns, I guess that you have some idea of what they are, but let's just make sure that we are on the same page:

Abstract definition: A design pattern is a proven technique that can be used to solve a specific problem.

In this book, we apply different patterns to solve different problems and how to leverage some open source tools to go further, faster! Abstract definitions make people sound intelligent and all, but there is no better way to learn than by experimenting with something, and design patterns are no different.

If that definition does not make sense to you yet, don't worry. You should have enough information at the end of the book to correlate the multiple practical examples and explanations with that definition, making it clear enough.

I like to compare programming to playing with LEGO® because what you must do is mostly the same: snap small pieces together to create something...

Anti-patterns and code smells are architectural bad practices or tips about possible bad design. Learning about best practices is as important as learning about bad ones, which is where we start. Moreover, there are multiple anti-patterns and code smells throughout the book to help you get started.

Unfortunately, we can't cover every detail of every topic, so I encourage you to dig deeper into those fields as well as into design patterns and architectural principles.

Anti-patterns

An anti-pattern is the opposite of a design pattern: it is a proven flawed technique that will most likely cause you some trouble and cost you time and money (and probably give you a headache or two along the way).

A priori, an anti-pattern is a pattern that seems to be a good idea, and that seems to be the solution that you were looking for, but in the end, it will most likely cause more harm than good. Some anti-patterns started out as legitimate design patterns...

Before going any further, it is imperative to understand the basic concept of the web. The idea behind HTTP 1.X is that a client sends an HTTP request to a server, and then the server responds to that client. That can sound trivial if you have web development experience. However, it is one of the most important web programming concepts, irrespective of whether you are building web APIs, websites, or complex cloud applications.

Let's reduce an HTTP request lifetime to the following:

1. The communication starts.
2. The client sends a request to the server.
3. The server receives the request.
4. The server most likely does something (executes some code/logic).
5. The server responds to the client.
6. The communication ends.

After that cycle, the server is no longer aware of the client. Moreover, if the client sends another request, the server is not aware that it responded to a request earlier for that same client...

A bit of history; the team did a magnificent job building ASP.NET Core from the ground up, cutting out compatibility with older versions. That brought its share of problems at first, but those interoperability issues got alleviated by the creation of .NET Standards. Now, with the reunification of most technologies into .NET 5 and the promise of a shared BCL, the name ASP.NET Core is (almost) no more, but became the future. Afterward, Microsoft is planning a major release of .NET every year, so 2021 should be .NET 6, and so on.

The good thing is that architectural principles and design patterns should remain relevant in the future and are not tightly coupled with the versions of .NET you are using. Minor changes to the code sample should be enough to migrate the knowledge and the code to the new versions.

Now, let's cover some key information surrounding .NET 5 and the .NET ecosystem.

.NET SDK versus runtime

You can install different binaries...

In this chapter, we peaked at design patterns, anti-patterns, and code smells. We also explored a few of those. We then moved to a reminder about the request/response cycle of a typical web application.

We continued by exploring .NET essentials, such as SDK versus runtime and app target versus .NET Standard. This sets us on the path to exploring the different possibilities that we have when it comes to building our .NET applications. We then dug a little more into the .NET CLI, where I laid down a list of essential commands, including dotnet build and dotnet watch run. We also covered how to create new projects.

In the next two chapters, we explore automated testing and architectural principles. These are foundational chapters for anyone wishing to build robust, flexible, and maintainable applications.

Let's take a look at a few practice questions:

1. Can we add a body to a GET request?
2. Why are long methods a code smell?
3. Is it true that .NET Standard should be your default target when creating libraries?
4. What is a code smell?

Here are some links to consolidate what has been learned in the chapter:

• Overview of how .NET Core is versioned: https://net5.link/n52L
• .NET Core CLI overview: https://net5.link/Lzx3
• Custom templates for dotnet new: https://net5.link/74i2