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. It could be a castle, a spaceship, or something else that you want to build. With that analogy in mind, a design pattern is a plan to assemble a solution that fits one or more scenarios; a tower or a reactor, for example. Therefore, if you lack imagination or skills in the case of LEGO®, possibly because you are too young, your castle might not look as good as someone else's that has more experience. Design patterns give you those tools, helping you build and glue beautiful and reliable pieces together to improve that masterpiece. However, instead of snapping LEGO® blocks together, you nest code blocks and interweave objects in a virtual environment!

Before going into more detail, well-thought-out applications of design patterns should improve your application designs. That is true when you design a small component or a whole system alike. However, be careful; throwing patterns into the mix just to use them can lead to the opposite. Aim to write readable code that solves the issue at hand, not at over-engineering systems with as many patterns as you can.

As we have briefly mentioned, there are design patterns applicable to multiple software engineering levels, and in this book, we start small and grow cloud-scale! We follow a smooth learning curve, starting with simpler patterns and code samples that bend good practices a little to focus on the patterns, and finally end with more advanced full stack topics, integrating multiple patterns and good practices.

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 and got labeled anti-patterns later. Sometimes, it is a matter of opinion, and sometimes the classification can be influenced by the programming language.

Anti-pattern – God class

A God class is a class that handles way too many things. It is usually a central class that many other classes inherit from or use; it is the class that knows and manages everything in the system; it is the class. On the other hand, it is also the class that nobody wants to update, and the class that breaks the application every time somebody touches it; it is an evil class!

The best way to fix this is to separate responsibilities and distribute them to multiple classes instead of only one. We see how to split responsibilities throughout the book, which helps create more robust software at the same time.

If you have a personal project with a God class at its core, start by reading the book, and then try to apply the principles and patterns that you learned to divide that class into multiple smaller classes that interact together. Try to organize those new classes into cohesive units, modules, or assemblies.

We are getting into architectural principles very soon, which opens the way to concepts such as responsibility segregation.

Code smells

A code smell is an indicator of a possible problem. It points to some areas of your design that could benefit from a redesign. We could translate code smell to the code that stinks.

It is important to note that code smells only indicate the possibility of a problem; it does not mean that there is one; they usually are good indicators though, so it is worth taking the time to analyze that part of the software.

An excellent example of this is when many comments are explaining the logic of a method. That often means that the code could be split into smaller methods with proper names leading to more readable code, and allowing you to get rid of those pesky comments.

Another thing about comments is that they don't evolve, so what often happens is that the code described by the comments has changed, but the comment remained the same. That leaves a false or obsolete description of a block of code that can lead a developer astray.

Code smell – Control freak

An excellent example of an anti-pattern is when you use the new keyword. That is an indication of a hardcoded dependency where the creator controls the new object and its lifetime. That is also known as the Control freak anti-pattern. At this point, you may be wondering how it is possible not to use the new keyword in object-oriented programming, but rest assured, we cover that and expand on the Control freak code smell in Chapter 7, Deep Dive into Dependency Injection.

Code smell – Long methods

A follow-up example that could be represented by our previous over-commented example would be long methods. When a method starts to extend to more than 10 to 15 lines of code, it is a good indicator that you should think about that method differently.

Here are a few examples of what could have happened:

• The method contains complex logic intertwined in multiple conditional statements.
• The method contains a big switch block.
• The method does too many things.
• The method contains duplications of code.

To fix this, you could do the following:

• Extract one or more private methods.
• Extract some code to new classes.
• Reuse the code from external classes.
• If you have a lot of conditional statements or a huge switch block, you could leverage a design pattern such as the Chain of Responsibility, or CQRS, which you will learn in Chapter 10, Behavioral Patterns and Chapter 14, Mediator and CQRS design patterns.

Usually, each problem has one or more solutions, suffice to spot the problem then find, choose, and implement the solution. Let's be clear here; a method containing 16 lines does not necessarily need refactoring; it could be OK. Remember that a code smell is merely an indicator of a problem, and is not necessarily a problem; apply common sense.

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 because HTTP is stateless.

There are mechanisms for creating a sense of persistence between requests in order for the server to become "aware" of its clients. The most well-known of these is probably cookies.

If we dig a little deeper, an HTTP request is composed of a header and an optional body. The most commonly used HTTP methods are GET and POST. Made popular by web APIs, we could also add PUT, DELETE, and PATCH to that list. Although not every HTTP method accepts a body, here is a list:

Here is an example of a GET request (without a body since that's not allowed for GET requests):

GET http://www.forevolve.com/ HTTP/1.1 Host: www.forevolve.com Connection: keep-alive Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9,fr-CA;q=0.8,fr;q=0.7 Cookie: ...

The HTTP header is composed of a list of key/value pairs representing metadata that a client wants to send to the server. In that case, I queried my blog using the GET method and Google Chrome attached some additional information to the request. I replaced the Cookie header's value with ... because cookies can be quite large and are irrelevant to this sample. Nonetheless, cookies are passed back and forth like any other HTTP header.

Important note about cookies

The client sends cookies, and the server returns them for every request-response cycle. That could kill your bandwidth or slow down your application if you pass too much information back and forth. I'm thinking of the good old Web Forms ViewState here.

When the server decides to respond to the request, it returns a header and an optional body as well, following the same principles as the request does. The first line indicates the status of the request; whether it was successful. In our case, the status code was 200, which indicates success. Each server can add more or less information to their response, as do you in your code.

Here is the response from the previous request:

HTTP/1.1 200 OK Server: GitHub.com Content-Type: text/html; charset=utf-8 Last-Modified: Wed, 03 Oct 2018 21:35:40 GMT ETag: W/"5bb5362c-f677"Access-Control-Allow-Origin: *Expires: Fri, 07 Dec 2018 02:11:07 GMT Cache-Control: max-age=600 Content-Encoding: gzip X-GitHub-Request-Id: 32CE:1953:F1022C:1350142:5C09D460 Content-Length: 10055 Accept-Ranges: bytes Date: Fri, 07 Dec 2018 02:42:05 GMT Via: 1.1 varnish Age: 35 Connection: keep-alive X-Served-By: cache-ord1737-ORD X-Cache: HIT X-Cache-Hits: 2 X-Timer: S1544150525.288285,VS0,VE0 Vary: Accept-Encoding X-Fastly-Request-ID: 98a36fb1b5642c8041b88ceace73f25caaf07746 HERE WAS THE BODY THAT WAS WAY TOO LONG TO PASTE; LOTS OF HTML!

Now that the browser has received the server's response, in the case of HTML pages, it starts rendering it. Then, for each resource, it sends another HTTP call to its URI and loads it. A resource is an external asset, such as an image, a JavaScript file, a CSS file, or a font.

Note

There are a limited number of parallel requests that a browser can send, which could lead to increased load time depending on the number of assets to load, their size, and the order in which they are sent to the browser. You may want to look into optimizing this.

After the response, the server is no longer aware of the client; the communication has ended. It is essential to understand that in order to create a pseudo state between each request, we need to use an external mechanism. That mechanism could be the session-state, or we could create a stateless application. I recommend going stateless whenever you can.

To conclude this subject, HTTP/2 is more efficient and supports streaming multiple assets using the same TCP connection. It also allows "server push," leading to a more stateful World Wide Web. If you find HTTP interesting, HTTP/2 is an excellent place to start digging deeper as well as the newest experimental HTTP/3.

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 grouped under SDKs and runtimes. The SDK allows you to build and run .NET programs, while the runtime only allows you to run .NET programs.

As a developer, you want to install the SDK on your deployment environment. On the server, you want to install the runtime. The runtime is lighter, while the SDK contains more tools, including the runtime.

.NET 5 versus .NET Standard

When building .NET projects, there are multiple types of projects, but basically, we could separate them into two categories:

• Applications
• Libraries

Applications are targeting a version of .NET, such as net5.0. Examples of that would be an ASP.NET application or a console application.

Libraries are bundles of code compiled together, often distributed as a NuGet package over NuGet.org. .NET Standard class library projects allow code to be shared between .NET Core, .NET 5+, and .NET Framework projects. .NET Standards came into play to bridge the compatibility gap between .NET Core and .NET Framework, which eased the transition. It was not easy when .NET Core 1.0 first came out.

With .NET 5 unifying all of the platforms and becoming the future of that unified .NET ecosystem, .NET Standards is no longer required.

Note

I'm sure that we are going to see .NET Standard libraries stick around for a while though. All projects are not going to migrate from .NET Framework to .NET 5 magically, and people are likely to want to continue sharing code between the two.

Next versions of .NET should be built over .NET 5, while .NET Framework 4.X is going to stay where it is today, receiving only security patches and minor updates.

Visual Studio Code versus Visual Studio versus the command-line interface (CLI)

How can one of those projects be created? .NET Core comes with the dotnet CLI, which exposes multiple commands, including new. Running the dotnet new command in a terminal generates a new project.

To create an empty class library, we can run the following commands:

md MyProject cd MyProject dotnet new classlib

That would generate an empty class library in the newly created MyProject directory. The -h option can come in handy when discovering available commands and their options. You can use dotnet -h to find the available SDK commands, or dotnet new -h to find out about options and available templates.

Visual Studio Code is my favorite text editor. I don't use it much for .NET coding, but I still do to reorganize projects, when the CLI time comes, or for any other task that is easier to complete using a text editor, such as writing documentation using markdown, writing JavaScript or TypeScript, or managing JSON, YAML, or XML files. To create a project or solution, or to add a NuGet package using VS Code, open a terminal and use the CLI.

As for Visual Studio, my favorite IDE, it uses the CLI under the hood to create the same projects, making it consistent between tools. Visual Studio adds a user interface over the CLI.

You can also create and install additional dotnet new project templates to the CLI or even create global tools. Those topics are beyond the scope of this book.

An overview of project templates

Here is an example of the templates that are installed (dotnet new):

Figure 1.1 – Project templates

A study of all the templates is beyond the scope of this book, but I'd like to visit the few that are worth mentioning or because we will use them later:

• dotnet new console creates a console application.
• dotnet new classlib creates a class library.
• dotnet new xunit creates an xUnit test project.
• dotnet new web creates an empty web project.
• dotnet new webapp creates an empty web project with a preconfigured Startup class.
• dotnet new mvc scaffolds an MVC application.
• dotnet new webapi scaffolds a web API application.

Async main (C# 7.1)

From C# 7.1 onward, a console application can have an async main method, which is very convenient as more and more code is becoming async. This new feature allows the use of await directly in the main() method, without any quirks.

Previously, the signature of the main method had to fit one of the following:

public static void Main() { }
public static int Main() { }
public static void Main(string[] args) { }
public static int Main(string[] args) { }

Since C# 7.1, we can also use their async counterpart:

public static async Task Main() { }
public static async Task<int> Main() { }
public static async Task Main(string[] args) { }
public static async Task<int> Main(string[] args) { }

Now, we can create a console that looks like this:

class Program
{
    static async Task Main(string[] args)
    {
        Console.WriteLine("Entering Main");
        var myService = new MyService();
        await myService.ExecuteAsync();
        Console.WriteLine("Exiting Main");
    }
}
public class MyService
{
    public Task ExecuteAsync()
    {
        Console.WriteLine("Inside MyService.ExecuteAsync()");
        return Task.CompletedTask;
    }
}

When executing the program, the result is as follows:

Entering Main
Inside MyService.ExecuteAsync()
Exiting Main

Nothing fancy, but it allows advantage to be taken of the await/async language feature.

Since .NET Core, all types of application start with a Main method (usually Program.Main), including ASP.NET Core 5 web applications.

Running and building your program

If you are using Visual Studio, you can always hit the play button, or F5, and run your app. If you are using the CLI, you can use one of the following commands (and more). Each of them also offers different options to control their behavior. Add the -h flag with any command to get help on that command, such as dotnet build -h:

Technical requirements

Throughout the book, we explore and write code. I recommend that you install Visual Studio, Visual Studio Code, or both, to help out with that.

Note

You could also use Notepad or your favorite text editor if you prefer. I use VS and VS Code. Choose the tools that you prefer.

Unless you install Visual Studio, which comes with the .NET SDK, you may need to install the .NET 5 SDK. The SDK comes with the CLI that we explored earlier, as well as the building tools for running and testing your programs. Have a look at the README.md file of the GitHub repository for more information and links to those resources.

The source code of all chapters is available for download on GitHub at the following address: https://net5.link/code.

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