You're reading from An Atypical ASP.NET Core 6 Design Patterns Guide A SOLID adventure into architectural principles and design patterns using .NET 6 and C# 10

Product type Paperback

Published in Mar 2022

Publisher Packt

ISBN-13 9781803249841

Length 678 pages

Edition 2nd Edition

Languages

Tools

.NET

Concepts

Design Patterns

Author (1):

Carl-Hugo Marcotte

View More author details

Table of Contents (31) Chapters

Preface

1. Section 1: Principles and Methodologies

2. Introduction FREE CHAPTER

3. Automated Testing

4. Architectural Principles

5. Section 2: Designing for ASP.NET Core

6. The MVC Pattern Using Razor

7. The MVC Pattern for Web APIs

8. Understanding the Strategy, Abstract Factory, and Singleton Design Patterns

9. Deep Dive into Dependency Injection

10. Options and Logging Patterns

11. Section 3: Designing at Component Scale

12. Structural Patterns

13. Behavioral Patterns

14. Understanding the Operation Result Design Pattern

15. Section 4: Designing at Application Scale

16. Understanding Layering

17. Getting Started with Object Mappers

18. Mediator and CQRS Design Patterns

19. Getting Started with Vertical Slice Architecture

20. Introduction to Microservices Architecture

21. Section 5: Designing the Client Side

22. ASP.NET Core User Interfaces

23. A Brief Look into Blazor

24. Assessment Answers

25. Acronyms Lexicon

26. Other Books You May Enjoy

27. Index

Appendices

1. Appendix A

2. Appendix B

Using external IoC containers

ASP.NET Core 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. If you are used to another IoC container and want to stick to it or require some missing advanced features, you might want to do that.

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

Use the built-in container.
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.
If it is impossible to achieve your goal, then swap it for another IoC container...