Book Image

An Atypical ASP.NET Core 5 Design Patterns Guide

By : Carl-Hugo Marcotte
Book Image

An Atypical ASP.NET Core 5 Design Patterns Guide

By: Carl-Hugo Marcotte

Overview of this book

Design patterns are a set of solutions to many of the common problems occurring in software development. Knowledge of these design patterns helps developers and professionals to craft software solutions of any scale. ASP.NET Core 5 Design Patterns starts by exploring basic design patterns, architectural principles, dependency injection, and other ASP.NET Core mechanisms. You’ll explore the component scale as you discover patterns oriented toward small chunks of the software, and then move to application-scale patterns and techniques to understand higher-level patterns and how to structure the application as a whole. The book covers a range of significant GoF (Gangs of Four) design patterns such as strategy, singleton, decorator, facade, and composite. The chapters are organized based on scale and topics, allowing you to start small and build on a strong base, the same way that you would develop a program. With the help of use cases, the book will show you how to combine design patterns to display alternate usage and help you feel comfortable working with a variety of design patterns. Finally, you’ll advance to the client side to connect the dots and make ASP.NET Core a viable full-stack alternative. By the end of the book, you’ll be able to mix and match design patterns and have learned how to think about architecture and how it works.
Table of Contents (27 chapters)
1
Section 1: Principles and Methodologies
5
Section 2: Designing for ASP.NET Core
11
Section 3: Designing at Component Scale
15
Section 4: Designing at Application Scale
21
Section 5: Designing the Client Side
25
Acronyms Lexicon

Using external IoC containers

ASP.NET Core 5 provides an extensible built-in IoC container out of the box. It is not the most powerful IoC container because it lacks some advanced features, but it can do the job for most applications. Rest assured, if it does not, you can change it for another. You might want to do that if you are used to another IoC container and want to stick to it or need missing advanced features.

As of today, Microsoft recommends using the built-in container first. If you don't know ahead of time all of the DI features that you will need, I'd go with the following strategy:

  1. Use the built-in container.
  2. When something cannot be done with it, look at your design and see if you can redesign your feature to work with the built-in container. This could help simplify your design, and at the same time, help maintain your software in the long run.
  3. If it is impossible to achieve your goal, then swap it for another IoC container.

Assuming...